[Python-checkins] r66799 - python/branches/release26-maint

Brett Cannon brett at python.org
Sun Oct 5 00:46:23 CEST 2008


On Sat, Oct 4, 2008 at 3:44 PM, Benjamin Peterson
<musiccomposition at gmail.com> wrote:
> On Sat, Oct 4, 2008 at 5:41 PM, Brett Cannon <brett at python.org> wrote:
>> On Sat, Oct 4, 2008 at 2:48 PM, Georg Brandl <g.brandl at gmx.net> wrote:
>>> Brett Cannon schrieb:
>>>> On Sat, Oct 4, 2008 at 2:06 PM, benjamin. peterson
>>>> <python-checkins at python.org> wrote:
>>>>> Author: benjamin.peterson
>>>>> Date: Sat Oct  4 23:06:11 2008
>>>>> New Revision: 66799
>>>>>
>>>>> Log:
>>>>> Blocked revisions 66721-66722,66744-66745,66752,66756,66763-66765,66768,66791-66792 via svnmerge
>>>>>
>>>>
>>>> If we have to block every change made in 2.7 that should not be
>>>> backported that is going to get old REALLY fast. If we use svnmerge on
>>>> 2.6 I think it should only be through explicit merging of specific
>>>> revisions and never through a across-the-board merge.
>>>
>>> Which is why I would have preferred merging in the other direction.
>>>
>>> Merging only manually loses one important factor of using svnmerge in the
>>> first place: not overlooking revisions to merge.
>>>
>>
>> Going the other direction works for me. Makes sense to have the
>> changes percolate up the versions.
>
> The problem with that is it makes blocking individual revisions for
> the py3k branch very hard.
>

How so? Can't you just block the revision that handled the merge to
the trunk? Or are you worried about the properties on '.' being
merged?

-Brett


More information about the Python-checkins mailing list