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>
Related
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.
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.
I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)
Can I rename a folder in Perforce from //depot/FooBar/ to //depot/Foobar/?
I've tried this by renaming from //depot/FooBar/ to //depot/Temp/ to //Depot/Foobar/ but the end result ends up the same as //depot/FooBar/.
Once it is in Perforce, the case remains set. As mentioned by Johan you can obliterate, set the name up correctly, and add it in again. However, there is a slight gotcha....
If anyone else (running Windows) has already synced the wrong-cased version, then when they sync again the right one, it will not change the case on their PC. This is a peculiarity of the Windows file system acknowledging case but still being fundamentally case-independent.
If a number of users have synced, and it is not convenient to get them to remove-from-client too (and blasting the folders from their machines), then you can resort to a dark and dirty Perforce technique called "Checkpoint surgery". It's not for the fainthearted, but you do this:
Stop your server, take a checkpoint.
Using your favourite text editor that can handle multi-megabyte files, search & replace all occurances of the old case name with the new. You could of course use a script too.
Replay your checkpoint file to recreate the Perforce database meta data.
Restart your server.
This will affect all user client specs transparently, and so when they sync they will get the right case as if by magic.
It sounds hairy, but I've had to do it before and as long as you take care, backup, do a trial run etc, then all should be OK.
Maybe not needed anymore, but here's the official Perforce HowTo about changing file cases on Windows and Unix: http://answers.perforce.com/articles/KB/3448/?q=change+file+case
I'm not sure about directories, but we've had this problem with files. To fix it, we have to delete the file, submit that change, then p4 add the file with the correct case and submit the second change. Once that's done, unix users who have sync'ed the incorrect-case file have to p4 sync, then physically delete the file (because p4 won't update the case) and then p4 sync -f the file.
Our server is on Windows, so that might make a difference.
I guess it treats files and folders the same.
For files:
It depends (on whether you have a Windows or Unix server). We have this problem with our Windows perforce server (which versions our Java code), where very occasionally someone will check in a file with a case problem (this then causes compile errors because it's Java). The only way to fix this is to obliterate the file and resubmit it with the correct case.
I think you should remove the Perforce Cache, so that your modification can be shown.
You can rename with ABC rename to abc_TMP, then abc_TMP rename to abc, then clear cache.
Setps to clear cache:
Open windows user home folder (on windows7 ==> C:\Users\)
Locate the folder called ".p4qt"
Rename the folder to "old.p4qt"
Launch Perforce, now everything works!
NOTE: these steps will rest your default setting.
The question is over 3 years old, but I ran into an issue like this while doing a Subversion import into Perforce and figured the info I got could be useful to some. It's similar to the obliterate method, but helps you retain history. You use the duplicate command that may not have been available back then to retain the history. The process basically being:
Duplicate to temporary location.
Obliterate the location you just duplicated.
Duplicate from the temporary location to the renamed case location.
Obliterate the temporary location.
Through this you retain the history of file changes, but get them all in the new path as well. Unfortunately there will be no history of the path case change, but that seems to be unavoidable. Similar to other methods mentioned here, users will need to either manually rename the directories in their workspace or delete and re-sync to get the new path name.
Also, P4V caches the paths it shows in the tree so after doing this it may still show up as the old name. a p4 dirs command however will show the new case.