On Wed, Jul 11, 2012 at 3:19 PM, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
> On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>> 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 seem to be implying that users having multiple svn clients on
> their system are the exception, rather than the rule. I think it's the
> other way around (though I haven't done the market research to back
> that up of course :-)). And all too often, regular users do *not* know
> the risks (but the manual upgrade is indeed a big help here).
>
> But I understand, we can't solve every problem on the planet (there
> needs to be some room left for educating users too :-)).
>
>> 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.
>
> I'm obviously not about to bear the burden myself, this thread was all
> about convincing you guys that this could be a burden worth bearing
> (and that maybe, with some creativity, the burden could be kept
> light).
>
> But okay, it seems I'm totally outnumbered (not a single voice of
> support in this thread). Fine. I concede.
I wasn't trying to push your opinion to the side, just pointing out
that you've a long row to hoe in trying to change the status quo. If
you feel passionate about it, by all means please continue to fight
the good fight.
(As for me, my view has now been made quite vociferously known, so I
will now fade back into the shadows.)
-Hyrum
Received on 2012-07-11 22:48:06 CEST