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