I've been using SVN to track my projects, and I've run into a problem several times.
svn: Directory "/programming/projects/mydirectory" containing working copy admin area is missing
I bet you're familiar with that one. What seems to be making this happen is when I try to "svn add" a directory that I don't have write permission to. Instead of saying "you don't have permission to do that, try something else," SVN puts my working copy in a messed-up state where it can't be updated or checked in.
Why does it do that? That seems like the Wrong Thing. I've searched up ways to fix this (the simplest thing seems to be "svn --force delete mydirectory") but I'm still puzzled as to why SVN can put my working copy in a messed-up state instead of throwing an error message based on a very simple condition.
Basically, there are many many ways to "partially" mess up your working directory.
By experience, I've never reached a situation where I've been unable to recover and where I had to get local diffs, remove my checkout, recheckout, reapply, ...
By playing quite a lot with: svn cleanup, revert/update folders that are in "!", remove some messy stuff, revert some wrongful adds, you always get back on your feet.
This is obviously a disadvantage, because you have much manual fiddling to do, but on the other hand, it's probably better to always err on the side of caution: when something unexpected happens, just make sure disk state is consistent is recoverable and stop, let the user see what exactly is wrong, rather than risking to make a bad decision.
Why complaining about this here? Create a script, which reproduces the bug and post it to the svn users mailing list. Then maybe the bug will be fixed. Your chances are much higher than here on stackoverflow..
You can even say that you have contributed to the subversion project.
Related
As part of my class, we have a project folder, and within it are individual files with a matching test file. When we download, that, we have to install npm, and as we finish each problem, we run mocha to test that our answers are correct.
Throughout, I would commit after each problem was solved, and then at the end, push it to a private github repo.
Now, I'm going back through the project, and I delete my answers so I can resolve them for practice, but running mocha doesn't work. Instead of seeing the 'passing' 'failing' in the terminal, I see the the console logs up to the problem I haven't done yet, which prints a reference error indicating I haven't declared the function (because I haven't reached that problem yet.
Other than deleting the code that I wrote, I've done nothing different, yet mocha won't work. Is there something else I need to do?
You're not giving us enough information to debug precisely what Mocha's complaining about, or enough information about your project so anybody could make any informed suggestions to help you.
No matter. SUGGESTION:
You're apparently using GitHub. Cool. Consider it your own little "time machine".
Save your current work. Either "git stash" (if you're comfortable with that), or simply back up your project folder to a temp directory).
Now revert back to a previous commit.
EXAMPLE:
git log # identify previous commits. Ideally, the last commit that "worked"
git checkout xxxxxxxxx # Check out out
Rinse and repeat until you find a commit that "works".
When you're done, you might wish to do something like this:
https://stackoverflow.com/a/21718540/421195
git revert --no-commit 0766c053..HEAD
git commit
This will revert everything from the HEAD back to the commit hash,
meaning it will recreate that commit state in the working tree as if
every commit after 0766c053 had been walked back. You can then commit
the current tree, and it will create a brand new commit essentially
equivalent to the commit you "reverted" to.
Git is your friend. It's useful as much more than simply a "source repository" to check in "completed code". You can also use it as a workaday tool for scenarios exactly like this.
Say my current project is called project_x. Normally, in the Project ToolWindow the outermost directory displayed would be the directory project_x, alongside things such as External Libraries. Kind of the default, as one would expect.
However, IntelliJ displayed a message that I cannot exactly remember, but which said something like "an external change has occured". It then asked me whether to rebuild the current project, and I did.
Problem: now, the outermost directory displayed is my User folder, i.e.: Username [project_x] -> IdeaProjects -> project_x
I find this annoying, and would like to know how to revert back to the default settings. Help would be appreciated.
What it currently looks like (it contains my entire user-dir):
What it should look like (ignore the theme):
Edit: Well, while it did work for the above project, it did not work for the other one (made matters worse tbh). So this probably is not a solution in general.
Ok, I figured it out.
I noticed that the blue square next to a directory means that it's the source root. (Both my users directory and my actual project directory had such a blue square, the former obviously not wanted...).
So I did some googling on how to remove such a source root. I didn't find the right answer, but got close enough to figure it out on my own (no idea if I caused any damage to my project though):
Go to File -> Project Structure -> Modules
After looking around I noticed that on the left side I had two modules, one of them having my users directory as source root. I deleted that one, which solved my problem.
I'd still appreciate it if somebody could explain to me why this happened, and how to avoid this in the future, because in the time between asking and answering this question, it has happened to me again...
So, we probably did something we shouldn't have done, but now I wonder how this should typically be handled.
We have a large project with multiple applications which are grouped in different sub-systems. I was working on one specific application which was found in the following subdirectory:
/svnroot/subSystemName/myApp
Since I didn't need the whole SVN, I just did a checkout of that subdirectory.
Some time later, someone else figured that the name of the sub-system wasn't quite right, so he did a svn rename on the directory, so that my application is now found in:
/svnroot/subSystemNewName/myApp
As you might imagine, this causes problems because when I try to do an update for instance, it says "target path does not exist", as it's still looking for the original path.
What am I to do? Is the only solution to do a full checkout again? How should this have been handled in the first place?
PS: I'm on Linux.
svn switch should do the trick. Run svn switch <url_of_new_location> <local_checkout_dir>
This happens occasionally in some projects I'm involved in that are using MKS as version control tool. A file is checked-out, modified and then checked-in but it was forgotten to be included in the related Change Package.
Is there a way to achieve this after the fact?
Thanks.
Delete revision (yes, the command exists), and then check in again, this time tied to the CP. Make sure you preserve the working file in the meantime.
If you've new revisions on top of it, you're out of luck.
I don't think that what SzG said really exists ( if so, I'd like to know too :) )
Once any operation is done without a CP, that operation can't be associated to a CP.
A solution for the future would be, to make using the CP mandatory in the project setup.
I'm a very fresh user of Perfoce, so please be patient!
I am trying to create a commit (I understand it that in Perforce it is called a changelist) of the files which have been changed. It sort of happens automatically in other VC systems, but there seems to be no easy way of doing it in p4... The problem is (maybe) that I'm not editing the files by hand, the files are generated (please don't ask me why do I have to check in the generated files...) so the whole directory tree is getting removed and then copied over with the new files. But Perforce acts as if nothing happened. In both my workspace and the depot it displays the updated files, but when someone will check them out on another machine, the files will be of the previous version.
I'm fine with doing it either through GUI or through the command line. I'd prefer the command line, because that would spare me the trouble in the long run, but it doesn't seem like it should be much hassle either way.
In other words, let's say, this is the workflow I'm used to from SVN or Git:
Run status to see what changed.
Stage / add to commit what you want to be in the next revision.
Commit and send it to the versioning server.
What I'm not able to do is the "stage" phase - because the changes are not discovered automatically.
EDIT
Ah, I think, I figured it out: reconciliation was what I needed... well, I guess if you don't marry, this word would hardly ever happen in your vocabulary :)
It appears that the proper command is reconcile. Also, as Bryan Pendleton suggested there should be status, but I must have an older version of Perforces, which doesn't have this command. This command is also available from context menu in either depot or workspace panels of Perforce graphical interface, when you click on the modified file.