[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 13:02:10 -0700

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.

> Longer answer:
>
> Because it currently breaks svnserve, at least on my machine.
> When no --listen is supplied, it will try to bind to multiple
> sockets by default, because I run dual IPv4/IPv6.
> Support for this isn't implemented yet -- instead, it runs
> into assert(false);

But if it was built on trunk, then you might have taken a slightly
different tack: only do multiple listeners if the right switches are
used. Then once you had the bug fixed, then you could have made it on
by default. Development is a bit harder to plan out when on mainline,
but it *does* get tested.

Cheers,
-g

---------------------------------------------------------------------
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-19 22:02:26 CEST

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.