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