Re: Format bump for 1.8?

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.

-- 
Johan