[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Finalizing what's in 1.5

From: Blair Zajac <blair_at_orcaware.com>
Date: Thu, 10 Jan 2008 12:04:54 -0800

David Glasser wrote:
> On Jan 10, 2008 2:18 PM, Ben Collins-Sussman <sussman_at_red-bean.com> wrote:
>> On Jan 10, 2008 1:04 PM, Blair Zajac <blair_at_orcaware.com> wrote:
>>
>>> Now after reading the IRC conversation, it appears that the amount of energy
>>> going into #2897 isn't going to be enough for a faster 1.5 release, there's
>>> nobody else really looking at the work. So if we want this feature, we should
>>> merge it soon into trunk and deal with it in trunk.
>> That's an interesting question: is the branch so unstable (at the
>> moment) that would make the trunk impossible to work on? If not,
>> there's no reason for the branch to persist.
>>
>> My vote is the same always (which doesn't have much weight, since I'm
>> not doing any work): Kamesh's branch is THE main use-case for
>> merge-tracking and svnmerge.py. An svn 1.5 release without the
>> ability to track and painlessly re-merge feature branches just isn't
>> interesting to the general public.
>
> The reintegrate branch gives the ability to track and painlessly
> re-merge feature branches.
>
> It may not give as much flexibility as the issue-2897 branch, but I'm
> still not actually convinced that the issue-2897 version will actually
> work as well.

Why is that? How does issue-2897 differ from the reintegrate branch? What use
cases are supported by one and not the other? I haven't been following these
branches closely enough to know the differences between them.

Blair

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-10 21:05:21 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.