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 '.'. Modified: python/branches/release30-maint/Doc/library/datetime.rst python/branches/release30-maint/Doc/reference/datamodel.rst Modified: python/branches/release30-maint/Doc/library/datetime.rst ============================================================================== --- python/branches/release30-maint/Doc/library/datetime.rst (original) +++ python/branches/release30-maint/Doc/library/datetime.rst Thu Jan 29 05:37:06 2009 @@ -1266,7 +1266,7 @@ :class:`tzinfo` Objects ----------------------- -:class:`tzinfo` is an abstract base clase, meaning that this class should not be +:class:`tzinfo` is an abstract base class, meaning that this class should not be instantiated directly. You need to derive a concrete subclass, and (at least) supply implementations of the standard :class:`tzinfo` methods needed by the :class:`datetime` methods you use. The :mod:`datetime` module does not supply Modified: python/branches/release30-maint/Doc/reference/datamodel.rst ============================================================================== --- python/branches/release30-maint/Doc/reference/datamodel.rst (original) +++ python/branches/release30-maint/Doc/reference/datamodel.rst Thu Jan 29 05:37:06 2009 @@ -1096,7 +1096,9 @@ is printed to ``sys.stderr`` instead. Also, when :meth:`__del__` is invoked in response to a module being deleted (e.g., when execution of the program is done), other globals referenced by the :meth:`__del__` method may already have - been deleted. For this reason, :meth:`__del__` methods should do the absolute + been deleted or in the process of being torn down (e.g. the import + machinery shutting down). For this reason, :meth:`__del__` methods + should do the absolute minimum needed to maintain external invariants. Starting with version 1.5, Python guarantees that globals whose name begins with a single underscore are deleted from their module before other globals are deleted; if no other
On Wed, Jan 28, 2009 at 10:37 PM, brett. cannon <python-checkins@python.org> 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 ." -- Regards, Benjamin
On Thu, Jan 29, 2009 at 08:04, Benjamin Peterson <benjamin@python.org> wrote:
On Wed, Jan 28, 2009 at 10:37 PM, brett. cannon <python-checkins@python.org> 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 ."
I was too tired after pushing the change to two other branches think about that. =) -Brett
Benjamin Peterson wrote:
On Wed, Jan 28, 2009 at 10:37 PM, brett. cannon <python-checkins@python.org> 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" <martin@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
Brett Cannon wrote:
On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" <martin@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
On Thu, Jan 29, 2009 at 19:03, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Brett Cannon wrote:
On Thu, Jan 29, 2009 at 18:27, "Martin v. Löwis" <martin@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
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 ---------------------------------------------------------------
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 ---------------------------------------------------------------
participants (5)
-
"Martin v. Löwis" -
Benjamin Peterson -
Brett Cannon -
brett.cannon -
Nick Coghlan