SVN: undo a merge with local changes - linux

I was on version 100, with local changes.
I did an svn up to reach HEAD (which is revision 200). Then I was ill adviced to revert back to revision 150, with my local changes, in command: svn merge -r HEAD:150 .
Now I actually want to go back to revision 200 with my local changes. svn up doesn't do anything, because I appear to still have file missings. I know because a file A.cpp was in revision 200 but not in my local working copy.
If I do svn status, I see a bizzare "D" in front of A.cpp. they seem to think I want to delete this file I don't even own.
What state am I in now, and how do I fix it?

In brief, your current checked out repo is messed up - it has a combination of your changes as well as a set of uncommitted changes to go back from HEAD -> r150. If you committed at this point, it would have the effect of removing all the changes that happened from 150:HEAD, and then adding in your changes.
If trying to do a re-merge: svn merge -r 150:HEAD . doesn't work (and generally it won't), then I would suggest the following:
assuming you have your current workspace <currws>
checkout a second copy of the workspace, at revision 150: svn co -r 150 <svn url> <newws>. This will give you a directory <newws>
(cd <currws>; tar cf - --exclude .svn .) | (cd <newws>; tar xf -). This will take all the files & directories from <currws> and copy them into <newws>.
Take inventory of the new directory - it should now contain copies of only your changes - some of these may need to be SVN added to the workspace; or if you have deletes, they will need to be re-deleted on the <newws>. You can pre-remove all the files/folders from new-ws prior to the tar, and anything that appears after the tar with a ! indicates a file that you removed with your changes, anything with a ? is a file that needs adding, and the remainder should be M entries.
Bring the new workspace up to HEAD - svn up <newws> should work in this case.
verify that everything's working and that it only contains your changes.
make a patch file, get it code reviewed and then commit it.
I'm pretty sure this will get you back on-track; although I don't have a tree to check against with the spotty network connectivity I have.

Related

I've deleted all the files in my directory. How can I get them back?

I'm new to Perforce and, to be honest, I'm hating it.
I had about 20 files in my c:\workspaces\perforce directory and I selected all of them and hit the delete key.
They were all checked in before I deleted them.
I've been pulling my hair out trying to figure out how to get them back (Perforce is sooooo unintuitive) but there's nothing that stands out to a n00b like me to.
How can I get the latest revisions back into the directory from Perforce?
You need to do a force sync.
On the command line:
$> p4 sync -f
In the P4V GUI:
Right-click on the directory to update
Select 'Get Revision'
In the dialog, check 'Force operation'
Click 'Get Revision'
The perforce server keeps track of which files you pulled in last time. This is done so that, the next sync only brings in the files which have changes since the last sync, instead of all the files once again.
To override this behavior, you need to use the -f option.
The -f flag forces resynchronization even if the client already has
the file, and overwriting any writable files. This flag doesn't
affect open files.
If you're using the command line client, you can run this command from the directory where you want to sync up:
p4 sync -f ...
You might also want to check the list of opened files, since sync -f will not be bringing in changes corresponding to those files (even if you have deleted them).
This command should list all the opened files:
p4 opened ...
If you have any files listed in the above list, which you had deleted as well, you should revert them before running sync -f.
p4 revert <FILE1> <FILE2>
p4 sync -f ...
If you're using p4v, you could follow the steps mentioned by dwinkle:
1. Right click the folder in your workspace
2. Choose `Get Revision` in the context menu.
3. Choose `Get Latest revision`
4. Check `Force Operation (replace file even if you already have the revision specified)
5. Click on `Get Revision` button to fetch the files.
To look at the list of opened files using p4v, you would have to look at your list of pending changelists. You should be looking in the default changelist, if you have not put the files in any speficic changelist. Right click on files that you see there that you had deleted earlier, and choose Revert.
if you have files checked out, and then deleted. You need to revert(p4 revert -a //...) the folder before you get latest forced (p4 sync -f).
An alternative:
p4 reconcile
p4 revert //...
If you don't care about the old client, one solution would be to pull down a new client:
p4 newclient
p4 sync
If you want the client to have the same name, you can do a forced sync as others have mentioned:
p4 sync -f
If you want the client to have the same name, but your directory is no longer recognized as a p4 workspace, you will need to delete the client and then recreate it.
p4 -c <client_name> client -d <client_name>
p4 newclient
Right click on parent directory.
Click "Reconcile" in context menu.
Let a new change list be created.
Right click changelist.
Revert change.
In my case I tried everything and I couldn't get all of my files to revert, so I tried deleting them and then I couldn't get all of them back. I restarted my pc, and tried numerous solutions found online. In the end my problem was solved by one or all of the following: upgrading to the latest P4V application, running the application with elevated permissions, and going to lunch after forcing get latest.
If you wasted half of a day. You may want to try the above.
I've deleted all the files in my directory. How can I get them back?
One wrinkle to this that I just stumbled over is that if you remove the directory you can't just use p4 sync -f to get it back. I wanted a complete clean version of the directory so I did a:
rm -rf directory1
However when I did a p4 sync -f directory1 on it, it spits out:
directory1 - no such file(s).
What I found that works is to recover a file inside of the directory first:
p4 sync -f directory1/some-file
You will have to know the name of one of the files inside of the missing directory which you can get using:
p4 files //depot/some/path/directory1/\*
Once you get one of the filenames, do:
p4 sync -f directory1/some-file
This should create the directory1 directory. Then you can do a full sync inside of the created directory:
cd directory1
p4 sync -f ...
Hope this helps someone else.

Piping the Results of git status to Subsequent Commands

I have a large list of active files in my Git repository. One change I made was deleting a large number of images across a number of directories. I want to commit that change immediately but I don't want to include all active files and I don't want to manually type out git rm myfile.png for every single image.
So essentially what I want to do is run git rm on all active files ending in .png. I'm trying to accomplish this by piping the results of git status into git rm but I'm having trouble isolating the file name and getting this to work as I'd like.
Is this a proper use of piping and if so what syntax do I need?
Any help is appreciated, thanks.
If you already removed the files, you can type:
git add -u
And they will be removed from git repository.
From git help add:
-u, --update
Only match <filepattern> against already tracked files in the index
rather than the working tree. That means that it will never stage
new files, but that it will stage modified new contents of tracked
files and that it will remove files from the index if the
corresponding files in the working tree have been removed.

ignoring a file in svn?

Im using command and just tried the following:
svn propset svn:ignore "conf.php"
However this opens up vim and if I exit the file svn-prop.tmp file is created.
I don't want to delete it as I need it, but I would love it if svn could just not list it when i svn st
What when wrong (conf.php is still listed when I svn st) and how do I correct it?
If conf.php has already been committed, then there are no ignore patterns you can throw at Subversion to get it to ignore the file.
What you probably want to do is:
svn mv conf.php conf.php.template. This will move conf.php to conf.php.template.
svn commit.
cp conf.php.template conf.php.
Assuming that you have already set the svn:ignore property, then this should do it. At this point, you will have a versioned conf.php.template file that you can modify when you want the configuration stored in the repository to change, and you have an unversioned conf.php that you can tweak locally without Subversion informing you that it needs to be committed.
If you check out the repository elsewhere, just make sure that you cp conf.php.template conf.php to set up the initial configuration; then you can tweak conf.php as needed.
you need to set the ignore property on the directory containing the file you want to ignore:
svn propedit svn:ignore .
then enter the filename(s) to ignore when your editor comes up

tortoisesvn lost history of file due to delete, then add of same file

I had a developer 'revert' a file by deleting it from the repository and re-adding it. We now have a current file with no history. Is there a way to get back the deleted file. With it having the same name as existing file, how should I proceed? Yes, I have tried to read the docs but can't seem to get the right combination of actions to take.
delete the file in your working copy
in the repository browser, go to the revision where the original file still existed (i.e. before it was replaced)
right-click on that file in that revision in the repository browser, execute "copy to working copy"
specify the path in your working copy as the "copy to"-target
Now you have your file back including the history.
see this thread here...
examining history of deleted file
to resurrect your file you can
svn copy url/of/file#lastrevisionthefileexisted -r lastrevisionthefileexisted path/to/workingcopy/file
On Linux, I solved the problem by following the steps on the command line:
svnadmin create TEST
svn co https://URL/svn/codes/JarLib/
Delete file or directory which is re-added
svn delete https://URL/svn/codes/JarLib/XXXX.jar -m "XXXX.jar history resurrect operation"
svn update
Use 'svn copy' command to get deleted file/directory with HISTORY. Revision number must be deleted file's/directory's last revision number!!!
svn copy https://URL/svn/codes/JarLib/XXXX.jar#22467 -r 22467 XXX.jar
Operation below will add XXXX.jar to your Working Copy then commit the changes.
svn commit -m "deleted file/directory is resurrected"
To control:
Go to SVN Server and use svnlook command like:
svnlook history /svn/repos/codes /JarLib/XXXX.jar --show-ids

How do I revert back to a previous SVN commit?

Suppose I'm at revision 50.
But, I want to revert back to revision 45, and commit back as the stable version.
How do I do that, in the most simple way?
What if I want to do that with one file?
What if I want to do that with the entire repository?
I'm not sure what you mean by "commit back as the stable version", but depending on what you're trying to accomplish I recommend:
svn update -r45
This will rebase your working copy at revision 45.
or:
svn merge -c -50,-49,-48,-47,-46
This will update (by reverse-merging) your working copy by removing all the changes between 45 and 50. Now if you make changes and commit, it will be like you have removed 46-50 from the repository and made the HEAD revision (51?) to be r45 + your change.
Reverse merge those revisions that you want to undo. This can be done on one or multiple files. By reverse merging, your working copy gets changed to the state without that revision, which you then can commit.
You can simply do an update to revision using
svn up -r 45
But this will not let you commit the changes as SVN needs you to update your working copy to HEAD before you can commit. What you can do instead is
svn merge -r HEAD:45 yourFile
svn ci yourFile -m "Reverting back to rev 45"
I think one simple way should be this:
checkout revision 45 to a temporary directory
copy one or alle files to your working directory
commit

Resources