Hi,
> Von: Johan Corveleyn [mailto:jcor...@gmail.com] > 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: > >> 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). Just some non-representative data from my last working environments: Logix: We had command line svn (Debian package) and subclipse (svnkit, from eclipse.org). Some users used other graphical frontends, but they're all from the debian repository, so they used the same libs as the command line tools, effectively giving 2 different client versions. Soloplan: Most coworkers had TortoiseSVN and AnkhSVN, and some had a command line client in addition. Giving 2 or 3 different client versions. 3S: Most coworkers have TortoiseSVN and AnkhSVN, some add a command line client, and very few ones (I'm the only one I'm aware of) use VisualSVN instead of AnkhSVN. As recent TortoiseSVN comes with the command line versions, and VisualSVN includes TortoiseSVN, this gives between 1 and 3 client versions for each user. In all of those environments, I remember gripes about client version mismatches from coworkers which were not aware of the working copy format compatibility issue, especially when one client was upgraded with levity (aka apt-get dist-upgrade, or the tortoise "a new version is available" screen) and the other client was not yet available in that new version, because it lags behind in the upgrade cygle. This was worsened by clients like TortoiseSVN which refuse to be installed in several versions in parallel. So my personal experience tells me that multiple-client scenarios are the common case, and that the deployment strategy (only using linux distro packages, or 3-in-1 bundles like VisualSVN) can reduce that problem. That said, I think the core SVN project should not put too much effort into support for old working copy formats. But we should clearly announce that an 1.X-Upgrade will need a working copy format bump, and encourage other client distributors (Tortoise, Visual, Ankh, Subclipse, ...) to do the same. Maybe we should also encourage linux distributions to ship both versions in parallel for some time, as e. G. Debian does with GCC or PostgreSQL, and advocate parallel installability of different releases for other clients, at least as long as we cannot upgrade all existing working copies (see the "cleanup needed" issue.) Best regards Markus Schaber -- ___________________________ We software Automation. 3S-Smart Software Solutions GmbH Markus Schaber | Developer Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50 Email: m.scha...@3s-software.com | Web: http://www.3s-software.com CoDeSys internet forum: http://forum.3s-software.com Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
