On 9/27/07, Eric Smith <[EMAIL PROTECTED]> wrote: > > Thomas Wouters wrote: > > > Unfortunately, that's not how it works :-) If you check something into > > the trunk, it will be merged into Py3k sooner or later. I may ask the > > original submitter for assistance if it's incredibly hard to figure out > > the changes, but so far, I only had to do that with the SSL changes. The > > decimal changes are being merged as I write this (tests running now.) Is > > there anything in particular that needs to be done for decimal in Py3k, > > besides renaming __div__ to __truediv__? > > > > If you re-eally need to check something into the trunk that re-eally > > must not be merged into py3k, but you're afraid it's not going to be > > obvious to the merger, please record the change as 'merged' using > > "svnmerge merge -M -r<revision>". Please take care when picking the > > revision ;) You can also just email me or someone else you see doing > > merges, as I doubt this will be a common occurance. > > I'm getting ready to port my PEP 3101 implementation (str.format() and > friends) from py3k back to 2.6. How do I make it obvious that this is > something that doesn't need to be ported to py3k? I'm not sure what > "obvious to the merger" means. Is a "backported" checkin comment good > enough? With any luck this will be done with a single checkin to the > trunk, and another checkin to py3k so that the implementations can > remain identical.
Funny, just a few hours ago Guido mentioned we (meaning I) should write this up in a PEP :) I'll do that in the next few weeks. Obvious to the merger means whatever the merger expects it to mean ;) Yes, checkin comments are good. If an automatic merge fails, and the code isn't straightforward to merge from just looking at the files, looking at the actual changes in both branches is the next step. If the comment says 'backport from py3k' (preferably with which version was backported), that makes it easy to ignore the whole change (but perhaps not later checkins.) After you backport, maintenance should be done in the trunk, not the py3k branch (except of course, for parts that don't apply to the trunk.) I just want to make sure I don't make life more difficult than necessary > for the folks doing the very valuable merge process. As long as you commit any given thing only once, it's pretty easy to work out. As soon as you find yourself (more than once) committing things to py3k and then realizing it should go to the trunk, you may be making life harder. I appreciate that you're careful about this though, thanks :) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
_______________________________________________ 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
