[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: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 10 Jan 2008 14:38:05 -0500

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.

I feel pretty much the same, and given that Kamesh's work touches on
something that already does not work, I do not see a lot of potential
to make things a lot worse than they are. To me the main question was
how to synch up this work with the reintegrate (and remove SQLite
work). ie. who should merge to trunk first?

I tend to think we should merge reintegrate branch to trunk, and then
get your branch caught up and also do the work to replace the usage of
SQLite in that branch, and then merge back to trunk.

Obviously the reverse could also be done.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
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 20:38:24 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.