On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>> ...
>>> 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?
>>
>> Or some third-party could just do this, and we wouldn't have to mess
>> with it at all. If there is a demand, somebody will step up and do
>> it, but I don't think we (as the Apache Subversion project) should too
>> much about it.
>
> That's true, but one of the problems I'm trying to solve here is users
> having different clients on their system, each with their own release
> cycle. Maybe one of those offers this back-compat feature (e.g.
> currently the one that uses svnkit under the hood), but not the other
> two. That problem can only be solved, I think, if the core project
> makes this a built-in supported feature.
We can not, and should not attempt to, solve every problem for every
user. Using heterogenous versions in the same environment has a set
of known risks (which were somewhat alleviated by the manual upgrade
step in 1.7, btw). We attempt to catch and prevent old clients from
corrupting newer working copies, but that's as far as I think we need
to go.
You have a different opinion, and I respect that, but the amount of
effort required to simultaneously support multiple active working copy
formats will probably prove prohibitive. Unless you are willing to
bear that burden yourself, it will probably be difficult convincing
the rest of the community that this departure from historic precedent
is worth the maintenance burden.
-Hyrum
Received on 2012-07-11 20:07:46 CEST