On Wed, Jul 11, 2012 at 8:07 PM, Hyrum K Wright <hy...@hyrumwright.org> wrote: > On Wed, Jul 11, 2012 at 12:25 PM, Johan Corveleyn <jcor...@gmail.com> wrote: >> On Wed, Jul 11, 2012 at 7:14 PM, Hyrum K Wright <hy...@hyrumwright.org> >> wrote: >>> On Wed, Jul 11, 2012 at 12:09 PM, Johan Corveleyn <jcor...@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
