Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated. Flow diagram ------------ trunk ---> release26-maint \-> py3k ---> release30-maint Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch. Christian
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <lists@cheimes.de> wrote:
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
Thanks, Christian! Questions: (1) If I commit a change to the trunk that I don't want to go into release26-maint, should I explicitly block it using svnmerge? (2) Same question for trunk -> py3k (3) Same question for py3k -> release30-maint. I'm guessing that the answers are (1) No, (2) Yes, (3) No. Mark
On Thu, Dec 4, 2008 at 11:23 AM, Mark Dickinson <dickinsm@gmail.com> wrote:
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <lists@cheimes.de> wrote:
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
Thanks, Christian!
Questions:
(1) If I commit a change to the trunk that I don't want to go into release26-maint, should I explicitly block it using svnmerge?
(2) Same question for trunk -> py3k
(3) Same question for py3k -> release30-maint.
I'm guessing that the answers are (1) No, (2) Yes, (3) No.
That is correct. We don't care too much about blocking for the release branches. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
On Thu, Dec 4, 2008 at 10:12 AM, Christian Heimes <lists@cheimes.de> wrote:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
You say "they are then merged." Does that mean if I commit something on the trunk, someone else will merge it for me? Or do I need to do it? The library is vastly different between 2.x and 3.x. I'm personally aware of the many changes related to httplib / urllib / xmlrpclib. I'm worried that it will be hard to decide how to "merge" things between the two versions. Jeremy
Christian
_______________________________________________ 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/jeremy%40alum.mit.edu
On Thu, Dec 4, 2008 at 12:18 PM, Jeremy Hylton <jeremy@alum.mit.edu> wrote:
On Thu, Dec 4, 2008 at 10:12 AM, Christian Heimes <lists@cheimes.de> wrote:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
You say "they are then merged." Does that mean if I commit something on the trunk, someone else will merge it for me? Or do I need to do it?
Generally, somebody else will do it if it is on the trunk and bound for py3k. (Bug fixes should be backported by the original committer.) Of course, if the change required in py3k is complicated and vastly different, I and the other mergers would appreciate it if you did it yourself.
The library is vastly different between 2.x and 3.x. I'm personally aware of the many changes related to httplib / urllib / xmlrpclib. I'm worried that it will be hard to decide how to "merge" things between the two versions.
Feel free to do it yourself.
Jeremy
-- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
Christian Heimes wrote:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
Apologies if this has been discussed before. I looked but didn't see anything. Given that at least 99% of the changes for the trunk will not get merged into release26-maint, doesn't it make more sense to merge the other way? That is, anything that gets checked in to release26-maint would potentially be merged into trunk. That would remove the huge number of merge blocks that will otherwise be required. Same fore py3k and release30-maint. Eric.
On Thu, Dec 4, 2008 at 12:52 PM, Eric Smith <eric@trueblade.com> wrote:
Christian Heimes wrote:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
Apologies if this has been discussed before. I looked but didn't see anything.
Given that at least 99% of the changes for the trunk will not get merged into release26-maint, doesn't it make more sense to merge the other way? That is, anything that gets checked in to release26-maint would potentially be merged into trunk. That would remove the huge number of merge blocks that will otherwise be required. Same fore py3k and release30-maint.
I think the percentage is a bit lower than that. Also, we haven't been using blocking with the maintenance branch so far; svnmerge.py is just a convenience. (It generates commit messages and has a simpler interface than a simple "svn merge" command.) -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner."
On Dec 4, 2008, at 1:52 PM, Eric Smith wrote:
Apologies if this has been discussed before. I looked but didn't see anything.
Probably has, just 'cause everything has been discussed before.
Given that at least 99% of the changes for the trunk will not get merged into release26-maint, doesn't it make more sense to merge the other way? That is, anything that gets checked in to release26-maint would potentially be merged into trunk. That would remove the huge number of merge blocks that will otherwise be required. Same fore py3k and release30-maint.
The directions of merges were established in the past at some point. Though they feel wrong (at least to you and me), the direction is what it is. I'd asked about the direction mostly because I can never remember after time away from working on the Python tree. That said, don't let Python's decision on the direction keep you from managing your own projects the right way. :-) In fact, it's reasonable to fix bugs on the release26-maint branch, migrate the patch to the trunk, and then use svnmerge.py from there to propagate the changes. -Fred -- Fred Drake <fdrake at acm.org>
Benjamin Peterson schrieb:
On Thu, Dec 4, 2008 at 12:52 PM, Eric Smith <eric@trueblade.com> wrote:
Christian Heimes wrote:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
Apologies if this has been discussed before. I looked but didn't see anything.
Given that at least 99% of the changes for the trunk will not get merged into release26-maint, doesn't it make more sense to merge the other way? That is, anything that gets checked in to release26-maint would potentially be merged into trunk. That would remove the huge number of merge blocks that will otherwise be required. Same fore py3k and release30-maint.
I've suggested that too; the counter-argument was that "most people don't want to care in which branch to commit something". I'm not too comfortable with this argument as it implies a certain ignorance on the part of our committers. As Fred says, it wasn't discussed anyway. Also, with svnmerge, it is not too late to change merging direction.
I think the percentage is a bit lower than that. Also, we haven't been using blocking with the maintenance branch so far; svnmerge.py is just a convenience. (It generates commit messages and has a simpler interface than a simple "svn merge" command.)
I *did* use blocking with the 2.6 branch when I last merged a whole batch of commits. As you say, by using svnmerge without blocking we only get a tool that can generate commit messages. However, with blocking we get something more valuable: we don't overlook backportable fixes anymore. So: yes, blocking is more work, but it gives something important in return. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Christian Heimes schrieb:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
As a side-note: this merging flow means that bugfix and feature commits may never be merged from trunk to py3k in one svnmerge batch. Else, they cannot be separated when merging from py3k to 30-maint. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Thu, Dec 4, 2008 at 13:21, Georg Brandl <g.brandl@gmx.net> wrote:
Benjamin Peterson schrieb:
On Thu, Dec 4, 2008 at 12:52 PM, Eric Smith <eric@trueblade.com> wrote:
Christian Heimes wrote:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
Apologies if this has been discussed before. I looked but didn't see anything.
Given that at least 99% of the changes for the trunk will not get merged into release26-maint, doesn't it make more sense to merge the other way? That is, anything that gets checked in to release26-maint would potentially be merged into trunk. That would remove the huge number of merge blocks that will otherwise be required. Same fore py3k and release30-maint.
I've suggested that too; the counter-argument was that "most people don't want to care in which branch to commit something". I'm not too comfortable with this argument as it implies a certain ignorance on the part of our committers. As Fred says, it wasn't discussed anyway.
That would make the rule for choosing which branch to first commit to be the one with the smallest version: 2.6 -> trunk -> 3.0 -> py3k That seems reasonable to me since that is really what the code branching is and how I suspect we will do things with a DVCS.
Also, with svnmerge, it is not too late to change merging direction.
If changing it to be like above is not an issue then I vote for the change.
I think the percentage is a bit lower than that. Also, we haven't been using blocking with the maintenance branch so far; svnmerge.py is just a convenience. (It generates commit messages and has a simpler interface than a simple "svn merge" command.)
I *did* use blocking with the 2.6 branch when I last merged a whole batch of commits. As you say, by using svnmerge without blocking we only get a tool that can generate commit messages. However, with blocking we get something more valuable: we don't overlook backportable fixes anymore.
So: yes, blocking is more work, but it gives something important in return.
The other perk of this ordering is you should be able to place a single block along the chain where the patch should stop and potentially be done with the merges if you are in a rush. That way people who do mass merges can just sequentially merge and not worry about where a patch should stop. -Brett
trunk ---> release26-maint \-> py3k ---> release30-maint
As a side-note: this merging flow means that bugfix and feature commits may never be merged from trunk to py3k in one svnmerge batch. Else, they cannot be separated when merging from py3k to 30-maint.
True. However, the same would be true for the merge flow 26 -> trunk -> 3.0 -> 3k In fact, that merge flow wouldn't support merging features *at all*: a feature added to trunk would need to flow through 3.0, which can't accept new features. Regards, Martin
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <lists@cheimes.de> wrote:
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
I'm running into problems making this work, with a trivial change: I committed r67590 (which adds a single assert to ast.c) to the trunk, then merged to 2.6 and py3k in r67592 and r67595 respectively. Then I tried: ../svnmerge.py merge -r67595 from the root directory of a clean copy of the release30-maint branch (svn status gives no output), and got conflicts on '.': property 'svnmerge-integrated' set on '.' property 'svnmerge-blocked' set on '.' --- Merging r67595 into '.': U Python/ast.c C . property 'svnmerge-integrated' set on '.' property 'svnmerge-blocked' deleted from '.'. I now have a new file dir_conflicts.prej that looks something like: Trying to change property 'svnmerge-integrated' from '/python/trunk:1-61437,...,67528,67590', but property has been locally changed from '/python/branches/py3k:1-67498,67522-67524,67539,67541,67559,67588' to '/python/trunk:1-61437,...,67467,67484,67528'. (where the ... abbreviates a big long list of revision numbers). Did I mess up somewhere, or does svnmerge not work on a revision that was itself the result of an svnmerge? Mark
On Fri, Dec 5, 2008 at 11:20, Mark Dickinson <dickinsm@gmail.com> wrote:
On Thu, Dec 4, 2008 at 3:12 PM, Christian Heimes <lists@cheimes.de> wrote:
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
I'm running into problems making this work, with a trivial change: I committed r67590 (which adds a single assert to ast.c) to the trunk, then merged to 2.6 and py3k in r67592 and r67595 respectively. Then I tried:
../svnmerge.py merge -r67595
from the root directory of a clean copy of the release30-maint branch (svn status gives no output), and got conflicts on '.':
property 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' set on '.'
--- Merging r67595 into '.': U Python/ast.c C .
property 'svnmerge-integrated' set on '.'
property 'svnmerge-blocked' deleted from '.'.
I now have a new file dir_conflicts.prej that looks something like:
Trying to change property 'svnmerge-integrated' from '/python/trunk:1-61437,...,67528,67590', but property has been locally changed from '/python/branches/py3k:1-67498,67522-67524,67539,67541,67559,67588' to '/python/trunk:1-61437,...,67467,67484,67528'.
(where the ... abbreviates a big long list of revision numbers).
Did I mess up somewhere, or does svnmerge not work on a revision that was itself the result of an svnmerge?
Someone might know better than me, but I am willing to bet you can't svnmerge a svnmerge revision. Since the svnmerge revision contains changes to the metadata on . that will conflict with the new svnmerge values that the svnmerge you are trying to do causes. But if I am right about this then won't that require blocking the svnmerge revision on release30-maint the svnmerge revision on py3k? Ugh. Is this getting to the point that we can only svnmerge between trunk and py3k and the maintenance branches just have to be managed the old-fashion way? And I have pinged the people helping me with the DVCS PEP in hopes of getting us moved off of svn sooner rather than later. -Brett
On Dec 5, 2008, at 2:20 PM, Mark Dickinson wrote:
Did I mess up somewhere, or does svnmerge not work on a revision that was itself the result of an svnmerge?
I ran into this yesterday as well with my patch to the cgi module. The work-around was to revert the change to that property and edit it manually. I think this is a significant issue, since editing that property is about as error-prone as it can be. I've not really looked at the code in svnmerge.py, so I'm not sure how hard it would be to fix. -Fred -- Fred Drake <fdrake at acm.org>
Fred Drake wrote:
On Dec 5, 2008, at 2:20 PM, Mark Dickinson wrote:
Did I mess up somewhere, or does svnmerge not work on a revision that was itself the result of an svnmerge?
I ran into this yesterday as well with my patch to the cgi module. The work-around was to revert the change to that property and edit it manually.
I think this is a significant issue, since editing that property is about as error-prone as it can be. I've not really looked at the code in svnmerge.py, so I'm not sure how hard it would be to fix.
I think we're discovering the real reasons why people generally prefer to use a DVCS when trying to manage multiple branches :P For now it looks like we might have to maintain 3.0 manually, with svnmerge only helping out for trunk->2.6 and trunk->py3k... Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
I think we're discovering the real reasons why people generally prefer to use a DVCS when trying to manage multiple branches :P
For now it looks like we might have to maintain 3.0 manually, with svnmerge only helping out for trunk->2.6 and trunk->py3k...
The problem seems to be trunk -> py3k -> 3.0. I had no issues with py3k -> 3.0. Christian
On Dec 5, 2008, at 5:31 PM, Nick Coghlan wrote:
I think we're discovering the real reasons why people generally prefer to use a DVCS when trying to manage multiple branches :P
Really? I don't. The issue has nothing to do with someone maintaining private change sets, or wanting to do development with local commits without having access to commit to the project. I expect (and someone from work has said they do as well) that Subversion 1.5's merge tracking would have handled this situation.
For now it looks like we might have to maintain 3.0 manually, with svnmerge only helping out for trunk->2.6 and trunk->py3k...
I don't know if I'll have time to look at svnmerge this weekend (with house guests and all), but I really don't expect it's a difficult problem to solve in the tool. The behavior suggests that this tiered set of branch relationships wasn't expected. -Fred -- Fred Drake <fdrake at acm.org>
Was there ever a conclusion to this? I need to merge the patches associated with issue 4597 from trunk to all the maintenance branches, and I'd like to avoid messing anyone up if possible. If I don't hear back, I'll plan to svnmerge directly from trunk to each of the branches, and then block my merge to py3k from being merged again to release30-maint. Thanks, Jeffrey On Thu, Dec 4, 2008 at 7:12 AM, Christian Heimes <lists@cheimes.de> wrote:
Several people have asked about the patch and merge flow. Now that Python 3.0 is out it's a bit more complicated.
Flow diagram ------------
trunk ---> release26-maint \-> py3k ---> release30-maint
Patches for all versions of Python should land in the trunk. They are then merged into release26-maint and py3k branches. Changes for Python 3.0 are merged via the py3k branch.
Christian
Jeffrey Yasskin wrote:
Was there ever a conclusion to this? I need to merge the patches associated with issue 4597 from trunk to all the maintenance branches, and I'd like to avoid messing anyone up if possible. If I don't hear back, I'll plan to svnmerge directly from trunk to each of the branches, and then block my merge to py3k from being merged again to release30-maint.
No - you should merge from the py3k branch to the release30-maint branch. Regards, Martin
Martin v. Löwis wrote:
Jeffrey Yasskin wrote:
Was there ever a conclusion to this? I need to merge the patches associated with issue 4597 from trunk to all the maintenance branches, and I'd like to avoid messing anyone up if possible. If I don't hear back, I'll plan to svnmerge directly from trunk to each of the branches, and then block my merge to py3k from being merged again to release30-maint.
No - you should merge from the py3k branch to the release30-maint branch.
I believe that's difficult when you previously merged from the trunk to the py3k branch - the merged change to the svnmerge related properties on the root directory gets in the way when svnmerge attempts to update them on the maintenance branch. That's what started this thread, and so far nobody has come up with a workaround. It seems to me that svnmerge.py should just be able to do a svn revert on the affected properties in the maintenance branch before it attempts to modify them, but my svn-fu isn't strong enough for me to say that for sure. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Thu, Dec 11, 2008 at 4:18 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Martin v. Löwis wrote:
Jeffrey Yasskin wrote:
Was there ever a conclusion to this? I need to merge the patches associated with issue 4597 from trunk to all the maintenance branches, and I'd like to avoid messing anyone up if possible. If I don't hear back, I'll plan to svnmerge directly from trunk to each of the branches, and then block my merge to py3k from being merged again to release30-maint.
No - you should merge from the py3k branch to the release30-maint branch.
I believe that's difficult when you previously merged from the trunk to the py3k branch - the merged change to the svnmerge related properties on the root directory gets in the way when svnmerge attempts to update them on the maintenance branch.
That's what started this thread, and so far nobody has come up with a workaround. It seems to me that svnmerge.py should just be able to do a svn revert on the affected properties in the maintenance branch before it attempts to modify them, but my svn-fu isn't strong enough for me to say that for sure.
Yeah, that's why I asked. I tried what Martin suggested with r67698 by just saying I'd resolved the conflict, which added the single revision I was merging from to the svnmerge-integrated property. It didn't add the two original revisions. I don't know enough about how svnmerge works to know if that's the right outcome or who it's going to cause trouble for. Jeffrey
I believe that's difficult when you previously merged from the trunk to the py3k branch - the merged change to the svnmerge related properties on the root directory gets in the way when svnmerge attempts to update them on the maintenance branch.
That's what started this thread, and so far nobody has come up with a workaround.
The work-around is fairly straight-forward: - inspect the conflict file (I forgot its name - something like dir-props), and verify that the only conflict is in the missing merge info from trunk to py3k - svn resolved .
It seems to me that svnmerge.py should just be able to do a svn revert on the affected properties in the maintenance branch before it attempts to modify them, but my svn-fu isn't strong enough for me to say that for sure.
See above. svnmerge overwrites the property after it has conflicted, so the only additional action to take is to declare that a resolution. Regards, Martin
Yeah, that's why I asked. I tried what Martin suggested with r67698 by just saying I'd resolved the conflict, which added the single revision I was merging from to the svnmerge-integrated property. It didn't add the two original revisions.
Can you elaborate? What are the "two original revisions" it didn't add? If you are referring to the trunk revisions - that's fine. As far as svnmerge is concerned, we merge revisions from the 3k branch to the 3.0 maintenance branch. The original revisions don't exist on the 3k branch (they have an empty changeset), so it's not a problem that they didn't get recorded as merged. Regards, Martin
On Thu, Dec 11, 2008 at 12:10 PM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
Yeah, that's why I asked. I tried what Martin suggested with r67698 by just saying I'd resolved the conflict, which added the single revision I was merging from to the svnmerge-integrated property. It didn't add the two original revisions.
Can you elaborate? What are the "two original revisions" it didn't add?
If you are referring to the trunk revisions - that's fine. As far as svnmerge is concerned, we merge revisions from the 3k branch to the 3.0 maintenance branch. The original revisions don't exist on the 3k branch (they have an empty changeset), so it's not a problem that they didn't get recorded as merged.
Yes, I was referring to the trunk revisions. Sounds like this (marking the conflicting property as resolved without changing it) is the way to go then. Thanks!
Martin v. Löwis wrote:
I believe that's difficult when you previously merged from the trunk to the py3k branch - the merged change to the svnmerge related properties on the root directory gets in the way when svnmerge attempts to update them on the maintenance branch.
That's what started this thread, and so far nobody has come up with a workaround.
The work-around is fairly straight-forward:
- inspect the conflict file (I forgot its name - something like dir-props), and verify that the only conflict is in the missing merge info from trunk to py3k - svn resolved .
Ah, that's the missing piece of info - thanks :) This should probably go in the dev FAQ somewhere though. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan wrote:
Martin v. Löwis wrote:
I believe that's difficult when you previously merged from the trunk to the py3k branch - the merged change to the svnmerge related properties on the root directory gets in the way when svnmerge attempts to update them on the maintenance branch.
That's what started this thread, and so far nobody has come up with a workaround. The work-around is fairly straight-forward:
- inspect the conflict file (I forgot its name - something like dir-props), and verify that the only conflict is in the missing merge info from trunk to py3k - svn resolved .
Ah, that's the missing piece of info - thanks :)
This should probably go in the dev FAQ somewhere though.
Indeed! Preferably with an example, if someone who understands it has the time. I have some changes I've been hold off of checking in until I see how someone else handles this. Eric.
participants (11)
-
"Martin v. Löwis" -
Benjamin Peterson -
Brett Cannon -
Christian Heimes -
Eric Smith -
Fred Drake -
Georg Brandl -
Jeffrey Yasskin -
Jeremy Hylton -
Mark Dickinson -
Nick Coghlan