Benjamin Peterson wrote:
On Wed, Jan 28, 2009 at 10:37 PM, brett. cannon
wrote: Author: brett.cannon Date: Thu Jan 29 05:37:06 2009 New Revision: 69093
Log: Backport r69092 by hand since svnmerge keeps saying there is a conflict on '.'.
Just do "svn resolved ."
There are potential problems with doing it that way [1]. The safer option is to do: svn revert . svnmerge merge -M -F <py3k-rev> Perhaps we should add a "maintmerge" script (along with "maintmerge.bat" batch file) to the root development directory that automates this: #/bin/sh svnmerge merge -r $1 svn revert . svnmerge -M -F $1 (Note that my shell scripting is a little rusty and I haven't actually executed that example...) Then the advice will just be to use svnmerge directly most of the time, and maintmerge when merging a revision that was itself created with svnmerge. Cheers, Nick. [1] How to clobber svnmerge's revision tracking 101: http://mail.python.org/pipermail/python-dev/2008-December/084644.html -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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
On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis"
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
Brett Cannon wrote:
On Thu, Jan 29, 2009 at 18:27, "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? 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
On Thu, Jan 29, 2009 at 19:03, "Martin v. Löwis"
Brett Cannon wrote:
On Thu, Jan 29, 2009 at 18:27, "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? 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
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
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@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan
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.
Antoine Pitrou wrote:
Nick Coghlan
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.
Ah, thanks - that's the piece I was missing regarding why the svn resolved trick works (I have used that approach before and checked it as you did - as Martin has pointed out, the only time it definitely goes wrong is if you do an update *after* doing the local merge and the update included other backports). So I'll chalk the fact that svnmerge emits that false alarm up to a deficiency in the tool and only use the "regenerate the metadata" approach when I suspect I may have done the merge+update in the wrong order (since it's a harmless thing to do - it just wastes a couple of minutes relative to the svn resolved approach). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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
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 | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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
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 | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
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 | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
(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
participants (4)
-
"Martin v. Löwis"
-
Antoine Pitrou
-
Brett Cannon
-
Nick Coghlan