While trying to help a coworker figure out where some unit tests went bad in the svn history, I hastily reverse merged a commit that I thought might have been the problem into his working copy:
svn merge -c -1234 .
then asked, "wait... you're working copy was clean right?". Unfortunately not. So a quick revert was not a good option. I tried to undo it cleanly ( svn merge -c 1234
) but nothing happened. Luckily he knew exactly which files were changed so we made a patch, reverted all modified files, and applied the patch. However, I'm wondering if there was a cleaner way to get out of this situation.
Your original idea was almost right. The Subversion way to do this would have been
svn merge -c 1234 . --ignore-ancestry
to re-apply the reverse-merged commit.
I realized that the reason svn merge -c 1234
did not work was we were already beyond revision 1234, so svn saw no need to do anything. A solution I tried at my desk later, which worked, was to download a diff of commit 1234, then apply it as a patch. Note that I used 1234
and not -1234
, which would have been a reverse diff.
svn diff -c 1234 > undo.patch
svn patch undo.patch
Had I been in the original situation again, this would have undone the reverse merge cleanly while preserving my coworker's changes.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.