[Python-checkins] [Python-Dev] Merging to the 3.0 maintenance branch

[Nick Coghlan]

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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------