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

Re: Format bump for 1.8?

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Wed, 11 Jul 2012 19:09:02 +0200

On Wed, Jul 11, 2012 at 5:29 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Jul 11, 2012 at 8:21 AM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>> On Wed, Jul 11, 2012 at 4:23 PM, C. Michael Pilato <cmpilato_at_collab.net>
>> wrote:
>> ...
>> > That said, I'm not really in favor of us maintaining multiple codepaths
>> > (based on WC version) in the client. I just don't see the cost
>> > justifying
>> > the benefit. I mean, it makes sense to do so in the repositories as we
>> > do
>> > today, because the cost of any Subversion upgrade could be equivalent to
>> > the
>> > cost of a full dump/load of the repository. I think that's too much to
>> > ask
>> > of our administrators. But for working copies?
>> On Wed, Jul 11, 2012 at 4:27 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> ...
>> > We have always had a problem delivering new features as fast as our
>> > users
>> > want to see them, I would hate to see us adopt new policies that just
>> > make
>> > it harder for us to turn the crank on new releases and new features. I
>> > would be against trying to support multiple formats for this reason.
>> Hmz. The fact that we don't deliver features as fast as our users want
>> is mainly a resources vs. effort issue. But this doesn't seem that
>> much different from any other "feature" to me (of course there is a
>> cost in developing the framework/infrastructure/... to support older
>> working copy formats). But maybe you're talking about a recurring
>> increase in effort for every release from now on.
> I think the effort would be enormous. As one example, we would need to
> figure out how to make our test suite test it and then ideally we would all
> run those tests with each change. Any time someone makes a change involving
> the WC they need to factor this in. I think it creates a fairly significant
> burden on almost every change that we make.

Concerning test effort, I think we can be pragmatic, and just not test
this systematically. Similar to how we currently support 1.7-server
with 1.x format repositories. I mean, does anyone systematically test
our 1.7.x release candidates with a 1.6 or 1.5 repository? The same
with our client-server compatibility: do we systematically test 1.7
clients with 1.6 or 1.0 servers? No, we might test those if someone
reports a specific issue, but other than that it's best effort ...

Concerning developers having to take this into account all the time:
yes that's true. They/we need to be aware of it and be careful not to
break the N-1-compat code. But how hard that is will depend on how we
implement this "feature".

For instance, we could simply package two set of binaries/libraries in
one package (the 1.8.0 version together with 1.7.x (taken from the
corresponding tag)), and implement a main wrapper that delegates
everything to the appropriate version. The 1.8.0 code doesn't need to
care about the 1.7-compat stuff, we just have a dispatcher and package
the old code together with it. I'm just fantasizing of course, for
illustrative purposes only :-). But ... it depends. Anyone have a
creative idea how this could technically be done and what the pros and
cons would be?

Received on 2012-07-11 19:09:55 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.