On Wed, Jul 11, 2012 at 9:23 AM, C. Michael Pilato <cmpil...@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
