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

["Martin v. Löwis"]

>> 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).

How so? The metadata are getting tracked just fine, no loss whatsoever.

> 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.

Take a look at r68901, which I merged using the procedure I described.

svn diff -r68900:68901 --depth empty .

gives

Modified: svnmerge-integrated
   -
/python/branches/py3k:1-67498,67522-67529,67531-67533,67535-67544,67546-67549,67551-67584,67586-67602,67604-67606,67608-67609,67611-67619,67621-67635,67638,67650,67653-67701,67703-67712,67714,67716-67746,67748,67750-67762,67764-67797,67799-67809,67811-67822,67825-67838,67840-67850,67852-67857,67859-67885,67888-67902,67904-67909,67911-67931,67933,67937-67938,67940,67950-67955,67957-67958,67960-67963,67965-67973,67975-67980,67982,67984-68014,68016-68058,68060-68089,68091-68093,68101,68103,68132,68137,68139-68152,68169-68170,68175,68178,68184,68193,68200,68205-68206,68212,68216,68223-68224,68226-68229,68237,68242,68245,68247,68249,68309,68321,68342,68363,68375,68401,68427,68440,68443,68451,68454,68463,68474-68475,68477,68508,68511,68525,68529,68553,68581,68587,68615,68619,68630,68638,68650-68653,68662,68669,68675,68677,68700,68709,68730,68732,68746,68767-68770,68782,68814-68815,68836,68855,68857,68887,68895
   +
/python/branches/py3k:1-67498,67522-67529,67531-67533,67535-67544,67546-67549,67551-67584,67586-67602,67604-67606,67608-67609,67611-67619,67621-67635,67638,67650,67653-67701,67703-67712,67714,67716-67746,67748,67750-67762,67764-67797,67799-67809,67811-67822,67825-67838,67840-67850,67852-67857,67859-67885,67888-67902,67904-67909,67911-67931,67933,67937-67938,67940,67950-67955,67957-67958,67960-67963,67965-67973,67975-67980,67982,67984-68014,68016-68058,68060-68089,68091-68093,68101,68103,68132,68137,68139-68152,68169-68170,68175,68178,68184,68193,68200,68205-68206,68212,68216,68223-68224,68226-68229,68237,68242,68245,68247,68249,68309,68321,68342,68363,68375,68401,68427,68440,68443,68451,68454,68463,68474-68475,68477,68508,68511,68525,68529,68553,68581,68587,68615,68619,68630,68638,68650-68653,68662,68669,68675,68677,68700,68709,68730,68732,68746,68767-68770,68782,68814-68815,68836,68855,68857,68887,68895,68898

As you can see, 68898 has been added to svnmerge-integrated, and this
is indeed the revision that I merged.


> 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 *only* interesting metadata in the svnmerge-integrated property
are the ones that svnmerge has written, and svnmerge writes them
correctly.

> 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).

Not with the procedure I described.

> 
> 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.

I don't understand why you bring up this "regardless of the relative
order"? Who ever proposed a different order? If you do things in the
order I suggest, everything will be fine, right?

> 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

That's open for debate. What *specific* wrong order are you talking
about? If you do things in the right order, will it still get the
bookkeeping wrong?

> 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).

See above. You claim that doing things the way I recommend will lose
metadata; I believe this claim is false.

Regards,
Martin