On Thu, May 28, 2009 at 04:50:35PM -0700, John Tannahill wrote:
> I have a subversion repository set up with a vendor drop. I am
> wondering if there is an easy way to handle the following situation:
>
> * I have done the latest vendor drop and have merged it with our
> local mods.
> * It is then decided that we would like to go back temporarily to the
> vendor drop from say 2 versions ago, but with our current locals
> mods still there.
> * First assume that their are no conflicts, moves, renames, deletes,
> etc. - everything would just neatly drop into place. Is there a
> straightforward way to do this?
Yes. Make a reverse diff of the vendor changes by diffing the vendor
branch at the right revisions:
svn diff -rVENDOR_CURRENT:VENDOR_2_VERSIONS_AGO http://.../branches/vendor
Once that looks right, merge the diff into trunk:
cd trunk/
svn merge -rVENDOR_CURRENT:VENDOR_2_VERSIONS_AGO ^/branches/vendor
# make sure everything looks ok, run tests etc.
svn commit -m "Reverting back to vendor drop from 2 versions ago".
You should see a message somewhat like:
--- Reverse-merging rX into '.':
I think that should do the trick.
> * What if it were more complicated - with conflicts, moves, renames,
> deletes, etc. - would subversion still be able to help me do this?
> For instance, could I roll back to two versions ago, and have
> subversion tell me what changed locally since then, and put these
> differences back in? Some automatically? Some manually?
The diff/merge works more or less the same way as above.
But with 1.5 there will be subtle problems. For sake of argument
let's just say the behaviour in conflict situations involving
deletes vs. textual modifications, moves vs. deletes etc. is
undefined for 1.5, because it effectively is.
As of Subversion 1.6, such structural conflicts (a.k.a. tree conflicts)
will be flagged.
See http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html
for a very basic introduction.
Note that due to limitations of Subversion some tree conflicts cannot
be detected, the most serious case being the incoming deletion of a
directory which contains local modifications.
This is detected and flagged as a tree conflict during an update,
were local modifications can only sit inside the target working copy.
But it is *not* yet detected during a merge where local modifications
exist in the _history_ of the target branch of the merge (i.e.
modifications which are unique to the target branch).
My recommendation is to play with complicated merges a little,
which contain situations like file deletions, renames, adds etc.
running against incompatible local changes, both in the current
working copy and in the history of the branch you are merging to
(i.e. make local changes, commit them, and *then* merge from another
branch). This will help you getting a feel for what Subversion
is capable of right now.
But note again that 1.5 cannot do any of this, you have to use 1.6.
And for best results, you'll need 1.6 on the server and the client.
A 1.6 client alone can already help, but less conflicts will be detected.
See also this file:
http://svn.collab.net/repos/svn/trunk/notes/tree-conflicts/use-cases-resolution.txt
It contains some example tree conflicts and possible resolutions.
But note that the file was created at a time when the user interface
for tree conflicts was still in development. So the output you'll
see from Subversion 1.6 won't match what is in this file.
Patches to update this file to use 1.6 output are very welcome!
The svnbook also needs to be more informative about tree conflicts
than it currently is.
> * Then once we decide to go with the newest vendor drop again, do I
> remerge it or can I somehow pull it out of the history I already
> have?
You can revert the diff you originally committed to go back to 2 versions
ago, but using a command like:
svn merge -c-REV_WHEN_MERGE_WAS COMMITTED .
(Note: MINUS c MINUS revnum, the second minus reverts the diff of the
specified revision, run 'svn help merge' for details.)
Or you can do a merge from the vendor branch again, but forward
instead of backward, by reversing the order of revisions specified
in the merge command -rVENDOR_2_VERSIONS_AGO:VENDOR_CURRENT
Hope this helps,
Stefan
Received on 2009-05-29 13:42:26 CEST