subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <>
Subject Re: auto-upgrade of working copy
Date Thu, 01 Jul 2010 22:05:00 GMT
On Thu, Jul 01, 2010 at 05:00:13PM -0400, Greg Stein wrote:
> Yup. I have dozens of working copies. The auto-upgrade is an awesome
> and useful feature. I don't have to worry about the fact that
> Subversion has changed something in its metadata. Why the heck should
> I care?
> The manual upgrade process is the odd-man-out here. As I mentioned
> earlier, we decided on that with *reluctance* because of the manual
> intervention that it will impose upon people. That we are monkeying
> with something so strongly, that we couldn't make it invisible to the
> user.
> "Easy" should be the prevailing case, and that means auto-upgrade.

Fair enough, we can default to auto-upgrade.

> Config options? Bleah. I dislike increasing the conceptual burden on
> our users ("hunh? should I set this? what is the impact? why do I need
> it? is this a good idea? am I gonna break something?").

Let's at least provide a config flag to disable it so users who really
don't want it can turn it off. If turned off, we provide an informative
prompt that asks the user if proceeding with the upgrade is fine and
warns about implications with multi-client use.

Then, when the day of server-side configuration finally comes, admins
can turn auto-upgrade off for all their users if they know that users will
(maybe just temporarily) be using multiple clients in incompatible versions.

I think this would make things a lot easier for users in environments
where tortoise, cli clients and various eclipse plugins all touch the
same working copies.
For this group of users, auto-upgrade is really annoying, especially
if people managing the client installations don't upgrade all svn clients

Actually, the problem is not so much in the upgrade itself (people
eventually realise what happened and get new WCs), but poor user
E.g. eclipse simply 'disconnects' unreadable working copies.
They're just gone. They disappear from the workspace after a CLI client
or tortoise upgraded them. This is highly confusing, so if we required
all svn clients using 1.7 and above to pass in a callback for prompting
users about the upgrade if the config says to do so, the user will at
least have been prompted and will know what has happened.

This make most sense with server-side configuration of course.
But that's already on the long-term road map.


View raw message