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

Re: svn commit: r35313 - in branches/http-protocol-v2: . subversion/mod_dav_svn subversion/mod_dav_svn/reports

From: Greg Stein <gstein_at_gmail.com>
Date: Wed, 21 Jan 2009 19:28:15 +0100

On Wed, Jan 21, 2009 at 18:20, Ben Collins-Sussman <sussman_at_red-bean.com> wrote:
> On Wed, Jan 21, 2009 at 10:28 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Greg Stein wrote:
>>> On Sun, Jan 18, 2009 at 17:37, Ben Collins-Sussman <sussman_at_red-bean.com> wrote:
>>>> ...
>>>> +++ branches/http-protocol-v2/subversion/mod_dav_svn/repos.c Sun Jan 18 08:37:15 2009 (r35313)
>>>> ...
>>>> @@ -307,6 +307,36 @@ parse_vcc_uri(dav_resource_combined *com
>>>> static int
>>>> +parse_rootstub_uri(dav_resource_combined *comb,
>>>> + const char *path,
>>>> + const char *label,
>>>> + int use_checked_in)
>>>> +{
>>>> + /* There are no components after the root stub, i.e. just
>>>> + "!svn/me/".
>>> Is this true? That a trailing slash can/will exist? I thought this
>>> resource was specified as NO trailing slash.
>>>> ...
>>> Changes like this one can/should appear on trunk. There is no reason
>>> to hide this on the branch.
>> I dunno, dude. With 1.6 looming in the near future, changes like this that
>> bring no value to the trunk -- merely the risks associated with
>> intended-to-be-but-not-really dead code -- are IMO unwelcome there.

Well... some things can go on trunk. Maybe not this one, but I'd
rather see More on trunk, whenever possible.

> Not only that, but it makes it very "clean" to have the v2 protocol
> implemented in one place -- not in piecemeal changes scattered across
> two different branches. I know our merge-tracking code is brilliant
> and all, but... :-)

No way, man. Then you just turn the branch into a Power Plant.

"Safe" stuff should be done on trunk, and then incorporated onto the
branch as part of your regular trunk-update.

Or: identify pieces of your v2 work that can be migrated back sooner
rather than later. A great example of this was hwright's checksum
work. We pulled that back to trunk well before the branch was merged.
Then people on trunk started propagating the checksum stuff throughout
the rest of the codebase. It worked out really well, and ensured that
the checksum stuff was SOLID when the branch finally got merged.

> That said, once 1.6 is released and the v2 protocol is "mostly"
> finished, I promise to merge the branch to trunk quickly. I'm not
> going to wait till it's perfect before merging.

Once 1.6 is branched, then I'd maintain you could continue your v2
work ON TRUNK. Why does it need to be separate? What is destabilizing
about your work? How would that harm trunk? You're adding
functionality into the server that nothing will be calling. So all
good there. Your client will start to look for new stuff, but people
running against old servers (e.g. svn.collab.net) will not invoke the
new (in-process) code.

Shoot. What if you do something wrong and the client doesn't properly
work with old servers? Having it on trunk means that ALL devs will see
it and fix it Sooner rather than Later.

Branch development sucks. Keep it on trunk, unless you have a *real*
good explanation why. Especially for a long-lead feature like http v2.


Received on 2009-01-21 19:28:34 CET

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