On 07/11/2012 09:50 AM, Johan Corveleyn wrote:
> Yes, I agree we'd have to make it clear in our docs that feature X
> depends on working copy format Y. That's an additional effort, yes.
> But for the book or the FAQ it's not a lot different from phrases
> where they now say: "If you've got Subversion 1.7 or higher, you'll
> get ...". Then they'll have to say "If your working copy format is 1.8
> or higher, you'll get ...".
Documentation-wise, I don't see this as much more problematic than "If
you're server was created with Subversion 1.5 or better, the mergeinfo
feature is available."
> As I said elsethread, most end-users I know consider the "manual
> upgrade" in 1.7 a clear improvement over auto-upgrading. It makes the
> entire process less scary. It avoids accidents like the scenario I
> mentioned, where the user has 3 svn clients (a commandline client, a
> GUI tool, and an IDE plugin), which all have their own release cycles.
> In that situation, an auto-upgrade by one of the three, while another
> can't be upgraded immediatly, can wreak havoc. It's much better to
> error out with 'working copy format too old, run svn upgrade'.
Agreed. Working copy auto-upgrade has been a repeated point of concern by
our users over the years, for the scenario you gave as well as for the
situation where users share working copies. (A similar situation drives the
reason why we don't auto-upgrade repositories -- multiple users hitting a
repository over ra_local with different client versions.)
That said, I'm not really in favor of us maintaining multiple codepaths
(based on WC version) in the client. I just don't see the cost justifying
the benefit. I mean, it makes sense to do so in the repositories as we do
today, because the cost of any Subversion upgrade could be equivalent to the
cost of a full dump/load of the repository. I think that's too much to ask
of our administrators. But for working copies?
I actually feel like the 1.7 situation was the best we've had to date:
restrictive WC format client support, an explicit upgrade step, minimal
surprises.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-07-11 16:24:32 CEST