Martin v. Löwis wrote: >> svn up >> svnmerge >> ... conflicts >> svn revert -R . >> svn up >> svnmerge >> ... same conflicts > > Ah. In the 3.0 branch, always do "svn revert ." after svnmerge. > It's ok (Nick says it isn't exactly ok, but I don't understand why)
Doing "svn revert ." before making the commit will lose the metadata changes that svnmerge uses for its bookkeeping (i.e. if this practice is used regularly, the tool will completely lose track of which revisions have already been merged). That won't bother those of us that are only backporting cherry-picked revisions, but is rather inconvenient for anyone checking for revisions that haven't been backported yet, but haven't been explicitly blocked either. Doing "svn resolved ." assumes that you did everything else correctly, and even then I don't see how svnmerge could both backport the py3k changes to the metadata and make its own changes and still get the metadata to a sane state. The consequence of getting this approach wrong is that the merge state of the 3.0 maintenance branch can be clobbered completely (losing track both of which revisions have been backported and which have been blocked). Doing both "svn revert ." and "svnmerge merge -M -F <revision>" clears out the conflicted metadata and then correctly updates the metadata for the revisions that have been backported. It will always update the svnmerge metadata correctly, regardless of the relative order of the svnmerge and svn update operations. Given the choice of a method which will always do the right thing, over one which always does the wrong thing and another one which only does the right thing if I did two other things in the right order and will completely trash the bookkeeping if I get it wrong, I prefer the option which is guaranteed to be correct (even if it happens to be a little slower as svnmerge recreates the needed metadata updates). If there's something wrong with my understanding of either svn properties or the operation of svnmerge that means the quicker approaches aren't as broken as I think they are, then I'd be happy to adopt one of them (since they *are* faster than my current approach). But until someone pokes a hole in my logic, I'll stick with the slower-but-always-correct methodology (and continue advocating that approach to everyone else doing updates that affect all four branches). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
