On Mon, May 19, 2008 at 3:26 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <[EMAIL PROTECTED]> wrote: >> On 2008-05-18 22:24, Brett Cannon wrote: >>> >>> On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: >>>> >>>> M.-A. Lemburg wrote: >>>>> >>>>> Perhaps I have a misunderstanding of the reasoning behind >>>>> doing the renaming in the 2.x branch, but it appears that >>>>> the only reason is to get used to the new names. That's a >>>>> rather low priority argument in comparison to the breakage >>>>> the renaming will cause in the 2.x branch. >>>> >>>> I think this is the key point here. The possibility of breaking pickling >>>> compatibility never came up during the PEP 3108 discussions, so wasn't >>>> taken >>>> into account in deciding whether or not backporting the name changes was >>>> a >>>> good idea. >>>> >>>> I think it's pretty clear that the code needs to be moved back into the >>>> modules with the old names for 2.6. The only question is whether or not >>>> we >>>> put any effort into making the new stdlib organisation usable in 2.x, or >>>> just rely on 2to3 to fix it (note that the "increasing the common subset" >>>> argument doesn't really apply, since you can catch the import errors in >>>> order to try both names). >>> >>> Problem with this is it makes forward-porting revisions to 3.0 a PITA. >>> By keeping the module names consistent between the versions merging a >>> revision is just a matter of ``svnmerge merge`` with the usual >>> 3.0-specific changes. Reverting the modules back to the old name will >>> make forward-porting much more difficult as I don't think svn keeps >>> rename information around (and thus map the old name to the new name >>> in terms of diffs). >> >> svnmerge is written in Python, so wouldn't it be possible to add >> support for maintaining such renaming to that tool ? > > svnmerge.py is mostly a wrapper over svn merge, and svn merge can't > handle it, so I don't think is easily possible.
I think MAL was suggesting add some property that kept track of skipped merges or something. >> >> I don't think that an administrative problem such as forward- >> porting patches to 3.x warrants breakage in the 2.x branch. > > I am a bit worried for the sanity of the Merger, though. Merges into > non-existent files are skipped automatically, so it doesn't make life > any easier. > It will either have to be done in 2.6 and the immediately forward-ported or done in 3.0 and backported. I will follow the latter IF I feel like bothering with the backport. > > <shameless_advertising>Bazaar can handle renames > correctly.</shameless_advertising> Yeah, yeah. One thing at a time. -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