On Wed, Jul 11, 2012 at 9:23 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> 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 agree with Mike on all of the above.
> 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
Agreed. Most of the feedback I've heard was that the 1.7 upgrade
experience was actually better than previous cycles, even though
technically t was the most radical.
Received on 2012-07-11 16:27:15 CEST