Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Martin v. Löwis wrote: I can see how svn resolved . gets it right (now that I understand how the conflict is being produced and then fixed automatically by svnmerge, but not actually marked as resolved). I still don't understand how svn revert . can avoid losing the metadata changes unless svnmerge is told to modify the properties again after they have been reverted. Or am I misunderstanding SVN, and the revert command doesn't actually revert property changes? Oops, I meant svn resolved . all the time. When I wrote svn revert ., it was by mistake. Ah, in that case we now agree on the right way to do things :) With the explanation as to where the (spurious) conflict is coming from on the initial merge to the maintenance branch, I'm now happy that the only time the revert + regenerate metadata should ever be needed is if someone else checks in a backport between the time when I start a backport and when I go to check it in (which is pretty unlikely in practice). 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Martin v. Löwis wrote: There are potential problems with doing it that way [1]. The safer option is to do: svn revert . svnmerge merge -M -F py3k-rev I still don't see the potential problem. If you do svnmerge, svn commit, all is fine, right? Sort of. svnmerge still gets confused by the fact that the revision being backported already has changes to the svnmerge metadata, so you have to either revert it (which is always wrong), or flag it as resolved (I believe that svnmerge actually does get that case right, but I haven't checked it extensively - since if it does get it right, I don't understand why it leaves the conflict in place instead of automatically marking it as resolved). Regardless, the consequences of forgetting that you did the svn up after the merge instead of before (e.g. if it took some time to get the backported version working, or if something interrupted you between the initial backport/update and the final test and commit step) are fairly hard to clean up, so I prefer the safe approach (despite the extra minute or two it takes for svnmerge to recalculate the metadata changes). 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Nick Coghlan ncoghlan at gmail.com writes: 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 metadata are discriminated by source merge URL. That is, the py3k metadata are of the form /python/trunk:list of revisions while the release30-maint metadata are of the form /python/branches/py3k:list of revisions. (*) I guess that's what allows svn to not shoot itself in the foot when merging. I did svn resolved . again yesterday and it doesn't seem to have borked anything. (*) (try svn propget svnmerge-integrated or svn propget svnmerge-blocked) Regards Antoine. ___ 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
(I believe that svnmerge actually does get that case right, but I haven't checked it extensively - since if it does get it right, I don't understand why it leaves the conflict in place instead of automatically marking it as resolved). I think this is a plain bug. It invokes svn merge, which creates a conflict, then removes the conflicted property (regardless of whether there was a conflict), then writes the property fresh. It doesn't consider the case that there might have been a conflict, just because such conflict didn't occur in their testing. Regardless, the consequences of forgetting that you did the svn up after the merge instead of before (e.g. if it took some time to get the backported version working, or if something interrupted you between the initial backport/update and the final test and commit step) are fairly hard to clean up, so I prefer the safe approach (despite the extra minute or two it takes for svnmerge to recalculate the metadata changes). If I find that it conflicts on commit, I rather restart all over. 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Martin v. Löwis wrote: See above. You claim that doing things the way I recommend will lose metadata; I believe this claim is false. I can see how svn resolved . gets it right (now that I understand how the conflict is being produced and then fixed automatically by svnmerge, but not actually marked as resolved). I still don't understand how svn revert . can avoid losing the metadata changes unless svnmerge is told to modify the properties again after they have been reverted. Or am I misunderstanding SVN, and the revert command doesn't actually revert property changes? 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
I can see how svn resolved . gets it right (now that I understand how the conflict is being produced and then fixed automatically by svnmerge, but not actually marked as resolved). I still don't understand how svn revert . can avoid losing the metadata changes unless svnmerge is told to modify the properties again after they have been reverted. Or am I misunderstanding SVN, and the revert command doesn't actually revert property changes? Oops, I meant svn resolved . all the time. When I wrote svn revert ., it was by mistake. 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
There are potential problems with doing it that way [1]. The safer option is to do: svn revert . svnmerge merge -M -F py3k-rev I still don't see the potential problem. If you do svnmerge, svn commit, all is fine, right? The problem *only* arises if you do svnmerge, svn up, svn commit - and clearly, you shouldn't do that. If, on commit, you get a conflict, you should revert all your changes, svn up, and start all over with the merge. 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
On Thu, Jan 29, 2009 at 18:27, Martin v. Löwis mar...@v.loewis.de wrote: There are potential problems with doing it that way [1]. The safer option is to do: svn revert . svnmerge merge -M -F py3k-rev I still don't see the potential problem. If you do svnmerge, svn commit, all is fine, right? The problem *only* arises if you do svnmerge, svn up, svn commit - and clearly, you shouldn't do that. If, on commit, you get a conflict, you should revert all your changes, svn up, and start all over with the merge. I did do that and I still got conflicts. -Brett ___ 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
Brett Cannon wrote: On Thu, Jan 29, 2009 at 18:27, Martin v. Löwis mar...@v.loewis.de wrote: There are potential problems with doing it that way [1]. The safer option is to do: svn revert . svnmerge merge -M -F py3k-rev I still don't see the potential problem. If you do svnmerge, svn commit, all is fine, right? The problem *only* arises if you do svnmerge, svn up, svn commit - and clearly, you shouldn't do that. If, on commit, you get a conflict, you should revert all your changes, svn up, and start all over with the merge. I did do that and I still got conflicts. What is that? svn revert -R (plus rm for all added files), svn up, svnmerge, svn revert .? What conflicts? 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
On Thu, Jan 29, 2009 at 19:03, Martin v. Löwis mar...@v.loewis.de wrote: Brett Cannon wrote: On Thu, Jan 29, 2009 at 18:27, Martin v. Löwis mar...@v.loewis.de wrote: There are potential problems with doing it that way [1]. The safer option is to do: svn revert . svnmerge merge -M -F py3k-rev I still don't see the potential problem. If you do svnmerge, svn commit, all is fine, right? The problem *only* arises if you do svnmerge, svn up, svn commit - and clearly, you shouldn't do that. If, on commit, you get a conflict, you should revert all your changes, svn up, and start all over with the merge. I did do that and I still got conflicts. What is that? svn revert -R (plus rm for all added files), svn up, svnmerge, svn revert .? svn up svnmerge ... conflicts svn revert -R . svn up svnmerge ... same conflicts What conflicts? Some metadata on '.'. -Brett ___ 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
Re: [Python-Dev] [Python-checkins] Merging to the 3.0 maintenance branch
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) 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
