[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Format bump for 1.8?

From: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Wed, 11 Jul 2012 09:26:40 -0500

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

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.

-Hyrum
Received on 2012-07-11 16:27:15 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.