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

Re: svn commit: r33748 - branches/issue-2382/subversion/svnserve

From: Greg Stein <gstein_at_gmail.com>
Date: Sun, 19 Oct 2008 17:23:33 -0700

On Sun, Oct 19, 2008 at 4:39 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Sun, Oct 19, 2008 at 4:02 PM, Greg Stein <gstein_at_gmail.com> wrote:
>> On Sun, Oct 19, 2008 at 12:13 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>>> On Sun, Oct 19, 2008 at 10:06:53AM -0700, Greg Stein wrote:
>>>> Why a separate branch for this? It seems that this could be
>>>> incrementally add in trunk without a major disruption.
>>> Short answer: What's wrong with branchy development?
>> It keeps the software from being used/tested by more people and the
>> buildbots. All the work that I've been doing on the WC is already
>> getting tested, and we recently found a bug when I made a global
>> read-only. If the development was on a branch, then it would not have
>> been noticed so early. And if it had waited until the remerge, then
>> tracking down the problem could have been mired in a morass of other
>> work.
>> Basically, you get zero testing during your development if you do it
>> on a branch.
> One thing we talked about at the summit last week (before you arrived)
> was that with the branch for 1.6 coming in the next couple weeks
> people ought to be conservative about what they are doing on trunk and
> try to limit it to stuff they can complete before the branch.

Fair enough.

On IRC, Stefan said he expected the branch to be short-lived, so the
question is somewhat moot.

But. That said, part of my question was also directed at overall
approach. Meta-level, if you will. IMO, we got screwed on 1.5 because
merge-tracking was developed on a branch. Keeping stuff out of the
main-line is simply asking for trouble, so I think if it can be done
on trunk (maybe with a little bit more precaution/work/overhead), then
it SHOULD be done on trunk.

Given that the branch is going to be short-lived, then (again, IMO) it
really should have been done on trunk. But if it will be rolled into
trunk soon, then ... whatever. Let it wrap on the branch, and get
merged back. It does seem like it is at-most maybe a week more of

As I'm sure you've noticed, I'm not doing my work on a branch. The
changes so far have been improvements to svn's core. Prep work.
Isolating those over on a branch doesn't do anybody any good. Yes, it
can easily be argued that it introduces instability, but ANY change
will, no matter where it is done. So that actually argues *more* for
trunk development where more people will see/test the change.


To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-20 02:23:51 CEST

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