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

Re: auto-upgrade of working copy

From: Stefan Sperling <stsp_at_elego.de>
Date: Fri, 2 Jul 2010 00:05:00 +0200

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.

Received on 2010-07-02 00:06:04 CEST

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