My company adopted a new process that included modifying the contents of 6000+ files and committing the changes to Subversion. The original programming that automatically performed the update messed up and we had to modify the 6000+ with another program and commit those modifications to Subversion.
Eventually, it occurred to everyone that the entire process was flawed and we had to undo all of the changes. What made this even more challenging was that developers across the company had modified the 6000+ files with their individual changes; we could not blindly remove the updates to all of the files.
I was tasked with removing the two bad commits while saving all of the individual developer edits. Luckily, Subversion provides the ability to perform reverse merging to remove bad revisions.
During the reverse merge I encountered 1000+ conflicts. This makes sense considering the type of modification; the same line was changed by the two autonomous processes and the developers. I did not feel like resolving these changes manually–after all, management wanted this done in a few hours–so I discovered a way to “auto accept” changes to resolve conflicts.
Step one: Lock out all developers during the update process. If I didn’t do this, I would never get my commit pushed through. I would need to constantly update my local copy and resolve conflicts prior to my massive commit. I set the appropriate permissions in the authz file to r from rw.
Step two: Refresh my local repository with the newest (head) revision and remove any of my local changes.
svn update
svn revert .\ -R
Step three: Remove revision 16044 from my working copy.
svn merge -r 16044:16043 svn://server/path --accept 'mine-full'
There are a few interesting things going on in the above statement. First, notice that the revision range goes backwards from 16044 to 16043. This is a reverse merge and instructs Subversion to remove revision 16044. The second interesting point is the use of –accept ‘mine-full’. This effectively tells Subversion to use the local version of the file (from head revision) if there are any conflicts. This preserves the manual updates made by developers since revision 16044.
I then removed the the other problematic revision, 16004.
svn merge -r 16004:16003 svn://server/path --accept 'mine-full'
Again, this preserves any manual changes made after revision 16004. Since I already removed 16044 from the working copy, only the developer edits remained. Obviously, you need to remove the higher revisions first and work your way to the lower revisions if you need to reverse merge more than one revision.
Step four: Commit working copy and re-enable Subversion for the other developers.
I hope this helps someone else out there. It took me a few hours to get the results I needed. BTW, I’m using version Subversion version 1.5. Happy SVN’ing!