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 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
