auto-upgrade of working copy

[Alan Barrett <ap...@cequrux.com>]

On Wed, 30 Jun 2010, Greg Stein wrote:
> Nope. Users cannot generally downgrade their client to run a cleanup.
> Historically, we have always auto-upgraded the working copies, even
> with stale logs in them.
> 
> The 1.7 upgrade process is too invasive and time-consuming, so we
> decided to have a manual process ('svn upgrade'). But moving forward,
> the intent is to continue an auto-upgrade mechanism even with stale
> workqueues.

The auto-upgrade has always bothered me.  I'd much prefer to have a
command line action (e.g. "svn upgrade") to upgrade the working copy,
and for the default behaviour to be that the client prints an error
message suggesting that the user should run "svn upgrade".

Many people use different clients in the same working copy (e.g. a
command line client and a GUI client), and it's a pain if one client
decides to upgrade the working copy to a format that the other client
doesn't support.  This gets even worse when working copies are shared by
multiple users (which happens a lot more often than I would like).

--apb (Alan Barrett)

RE: auto-upgrade of working copy

[Daniel Shahaf <d....@daniel.shahaf.name>]

We haven't done this so far, but there's the option of allowing svn 1.8 to 
write into 1.7 wc's (thus making 'svn upgrade' an optional-to-run command) 
--- just as we do on the server (repos) end.

Bolstridge, Andrew wrote on Thu, 1 Jul 2010 at 11:23 -0000:
> > -----Original Message-----
> > From: Alan Barrett [mailto:apb@cequrux.com]
> > Sent: Thursday, July 01, 2010 8:26 AM
> > To: dev@subversion.apache.org
> > Subject: auto-upgrade of working copy
> > 
> [snip]
> > The auto-upgrade has always bothered me.  I'd much prefer to have a
> > command line action (e.g. "svn upgrade") to upgrade the working copy,
> > and for the default behaviour to be that the client prints an error
> > message suggesting that the user should run "svn upgrade".
> > 
> > Many people use different clients in the same working copy (e.g. a
> > command line client and a GUI client), and it's a pain if one client
> > decides to upgrade the working copy to a format that the other client
> > doesn't support.
> > 
> 
> Can I second this - a little while back TortoiseSVN was upgraded to svn
> 1.6, but AnkhSVN hadn't been recompiled to use it - as a result, working
> copies could not be used by Ankh in Visual Studio, or if you wanted to
> use AnkhSVN, you had to stop using the new TortoiseSVN. The guys at
> AnkhSVN did issue a new version, but only after a few weeks. 
> 
> Next time, I would manage a rollout of 1.7 clients now, waiting until
> all clients we use had been upgraded before blindly upgrading as soon as
> the new version was available. That's probably the best system to use,
> and an auto-upgrade would be preferable. If the release notes gave a big
> warning reminder about this, that might be the best means of managing WC
> upgrades.
> 
> 

RE: auto-upgrade of working copy

["Bolstridge, Andrew" <an...@intergraph.com>]

> -----Original Message-----
> From: Alan Barrett [mailto:apb@cequrux.com]
> Sent: Thursday, July 01, 2010 8:26 AM
> To: dev@subversion.apache.org
> Subject: auto-upgrade of working copy
> 
[snip]
> The auto-upgrade has always bothered me.  I'd much prefer to have a
> command line action (e.g. "svn upgrade") to upgrade the working copy,
> and for the default behaviour to be that the client prints an error
> message suggesting that the user should run "svn upgrade".
> 
> Many people use different clients in the same working copy (e.g. a
> command line client and a GUI client), and it's a pain if one client
> decides to upgrade the working copy to a format that the other client
> doesn't support.
> 

Can I second this - a little while back TortoiseSVN was upgraded to svn
1.6, but AnkhSVN hadn't been recompiled to use it - as a result, working
copies could not be used by Ankh in Visual Studio, or if you wanted to
use AnkhSVN, you had to stop using the new TortoiseSVN. The guys at
AnkhSVN did issue a new version, but only after a few weeks. 

Next time, I would manage a rollout of 1.7 clients now, waiting until
all clients we use had been upgraded before blindly upgrading as soon as
the new version was available. That's probably the best system to use,
and an auto-upgrade would be preferable. If the release notes gave a big
warning reminder about this, that might be the best means of managing WC
upgrades.

Re: auto-upgrade of working copy

[Daniel Shahaf <d....@daniel.shahaf.name>]

Stefan Sperling wrote on Thu, 1 Jul 2010 at 12:33 -0000:
> This does not harm people using a single client much, but helps users
> who use several clients simultaneously a lot (they don't have to get
> fresh WCs to continue getting work done).

Including devs around the time of WC format bumps.  :-)

Re: auto-upgrade of working copy

[Daniel Shahaf <d....@daniel.shahaf.name>]

Mark Phippard wrote on Thu, 1 Jul 2010 at 13:45 -0400:
> Due to the way TSVN is integrated into Windows you can only have one
> version installed.  So this scenario really cannot happen, other than
> doing a complete uninstall of 1.6 and reinstalling 1.5.

Then let's assume that they either do a complete reinstall as you say, or 
use some other client.  (My point wasn't specific to TSVN.)

Re: auto-upgrade of working copy

[Mark Phippard <ma...@gmail.com>]

On Thu, Jul 1, 2010 at 1:24 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> I would guess a good percentage of those users, likely the majority,
>> use no other SVN client.
>
> There is the "I have TSVN 1.5 and want to try TSVN 1.6 without
> irreversibly breaking all my working copies" scenario.
>
> (I would guess not everyone who uses TSVN is going to create a test
> repository, populate it, and checkout it just in order to play with
> a new TSVN version; or maybe they have other reasons for wanting to play
> with the new version on their everyday WC)

Due to the way TSVN is integrated into Windows you can only have one
version installed.  So this scenario really cannot happen, other than
doing a complete uninstall of 1.6 and reinstalling 1.5.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: auto-upgrade of working copy

[Daniel Shahaf <d....@daniel.shahaf.name>]

Mark Phippard wrote on Thu, 1 Jul 2010 at 10:38 -0400:
> On Thu, Jul 1, 2010 at 10:33 AM, Stefan Sperling <st...@elego.de> wrote:
> 
> >> We are only ever going to hear the complaints.  That does not mean
> >> they speak for the majority of users.
> >
> > Oh, I didn't mean to imply that I'd expect people to write in
> > out of the blue, asking for the feature to be kept.
> >
> > I meant to say that I cannot recall any user ever requesting
> > that auto-upgrades be kept during a discussion about whether
> > or not auto-upgrades should be happening or not.
> >
> > Is there anyone? If so, speak up, now is your chance :)
> 
> Well TortoiseSVN, as an example, has been downloaded over 22 million times:
> 
> http://sourceforge.net/top/topalltime.php?type=downloads
> 
> I would guess a good percentage of those users, likely the majority,
> use no other SVN client.

There is the "I have TSVN 1.5 and want to try TSVN 1.6 without
irreversibly breaking all my working copies" scenario.

Daniel
(I would guess not everyone who uses TSVN is going to create a test
repository, populate it, and checkout it just in order to play with
a new TSVN version; or maybe they have other reasons for wanting to play 
with the new version on their everyday WC)

Re: auto-upgrade of working copy

[Stefan Sperling <st...@elego.de>]

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

Actually, the problem is not so much in the upgrade itself (people
eventually realise what happened and get new WCs), but poor user
interfaces.
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.

Stefan

Re: auto-upgrade of working copy

[Greg Stein <gs...@gmail.com>]

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.

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?").

Cheers,
-g

On Thu, Jul 1, 2010 at 11:20, Bob Jenkins <rj...@collab.net> wrote:
> I think the question you'd get a better response on would be do they use
> multiple clients on a single working copy. That's really the only
> scenario where they are likely to not want to upgrade the working copy.
> Not to say there aren't other edge cases, but this change would seem to
> mainly play to this group. The others are just having to take an action
> they want 90+% of the time.
>
> Bob Jenkins
>
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer@amsi.com]
> Sent: Thursday, July 01, 2010 10:48 AM
> To: Mark Phippard; dev@subversion.apache.org
> Subject: RE: auto-upgrade of working copy
>
> tortoise is a GUI and it could present a simple "Ok to upgrade your
> working copy" dialog.
>
> Perhaps an email on the user list to do an informal poll?
>
> BOb
>
>

RE: auto-upgrade of working copy

[Bob Jenkins <rj...@collab.net>]

I think the question you'd get a better response on would be do they use
multiple clients on a single working copy. That's really the only
scenario where they are likely to not want to upgrade the working copy.
Not to say there aren't other edge cases, but this change would seem to
mainly play to this group. The others are just having to take an action
they want 90+% of the time.

Bob Jenkins

-----Original Message-----
From: Bob Archer [mailto:Bob.Archer@amsi.com] 
Sent: Thursday, July 01, 2010 10:48 AM
To: Mark Phippard; dev@subversion.apache.org
Subject: RE: auto-upgrade of working copy

tortoise is a GUI and it could present a simple "Ok to upgrade your
working copy" dialog. 

Perhaps an email on the user list to do an informal poll? 

BOb

RE: auto-upgrade of working copy

[Bob Archer <Bo...@amsi.com>]

> >> We are only ever going to hear the complaints.  That does not
> mean
> >> they speak for the majority of users.
> >
> > Oh, I didn't mean to imply that I'd expect people to write in
> > out of the blue, asking for the feature to be kept.
> >
> > I meant to say that I cannot recall any user ever requesting
> > that auto-upgrades be kept during a discussion about whether
> > or not auto-upgrades should be happening or not.
> >
> > Is there anyone? If so, speak up, now is your chance :)
> 
> Well TortoiseSVN, as an example, has been downloaded over 22
> million times:
> 
> http://sourceforge.net/top/topalltime.php?type=downloads
> 
> I would guess a good percentage of those users, likely the
> majority,
> use no other SVN client.  In the Eclipse world we certainly have a
> decent number of users that do not know what a command line is or
> use
> any other client (probably not a majority of users though).
> 
> I think anyone that basically just uses one client enjoys the fact
> that they do not have to think about this aspect of Subversion.  We
> will soon enough learn if having to take a specific upgrade step
> introduces any usability problems for these users.
> 
> As I said though, I still think the explicit upgrade makes sense.
> It
> might cause some pain though.
> 

tortoise is a GUI and it could present a simple "Ok to upgrade your working copy" dialog. 

Perhaps an email on the user list to do an informal poll? 

BOb

Re: auto-upgrade of working copy

[Mark Phippard <ma...@gmail.com>]

On Thu, Jul 1, 2010 at 10:33 AM, Stefan Sperling <st...@elego.de> wrote:

>> We are only ever going to hear the complaints.  That does not mean
>> they speak for the majority of users.
>
> Oh, I didn't mean to imply that I'd expect people to write in
> out of the blue, asking for the feature to be kept.
>
> I meant to say that I cannot recall any user ever requesting
> that auto-upgrades be kept during a discussion about whether
> or not auto-upgrades should be happening or not.
>
> Is there anyone? If so, speak up, now is your chance :)

Well TortoiseSVN, as an example, has been downloaded over 22 million times:

http://sourceforge.net/top/topalltime.php?type=downloads

I would guess a good percentage of those users, likely the majority,
use no other SVN client.  In the Eclipse world we certainly have a
decent number of users that do not know what a command line is or use
any other client (probably not a majority of users though).

I think anyone that basically just uses one client enjoys the fact
that they do not have to think about this aspect of Subversion.  We
will soon enough learn if having to take a specific upgrade step
introduces any usability problems for these users.

As I said though, I still think the explicit upgrade makes sense.  It
might cause some pain though.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: auto-upgrade of working copy

[Stefan Sperling <st...@elego.de>]

On Thu, Jul 01, 2010 at 10:19:08AM -0400, Mark Phippard wrote:
> On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling <st...@elego.de> wrote:
> >> The auto-upgrade has always bothered me.  I'd much prefer to have a
> >> command line action (e.g. "svn upgrade") to upgrade the working copy,
> >> and for the default behaviour to be that the client prints an error
> >> message suggesting that the user should run "svn upgrade".
> >
> > I have repeatedly heard similar complaints and would therefore prefer
> > an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> > starting with 1.7. And I have never heard anyone asking for the auto-upgrade
> > feature to be kept.
> 
> I am not against having an svn upgrade, but it seems worth noting why
> would anyone bother to report that they want you to keep a feature
> they already have?  If users are happy with auto-upgraded working
> copies, which is all we ever gave them, why would they feel the need
> to post requests to keep the feature?
> 
> We are only ever going to hear the complaints.  That does not mean
> they speak for the majority of users.

Oh, I didn't mean to imply that I'd expect people to write in
out of the blue, asking for the feature to be kept.

I meant to say that I cannot recall any user ever requesting
that auto-upgrades be kept during a discussion about whether
or not auto-upgrades should be happening or not.

Is there anyone? If so, speak up, now is your chance :)

Stefan

Re: auto-upgrade of working copy

[Stefan Sperling <st...@elego.de>]

On Thu, Jul 01, 2010 at 10:19:08AM -0400, Mark Phippard wrote:
> On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling <st...@elego.de> wrote:
> >> The auto-upgrade has always bothered me.  I'd much prefer to have a
> >> command line action (e.g. "svn upgrade") to upgrade the working copy,
> >> and for the default behaviour to be that the client prints an error
> >> message suggesting that the user should run "svn upgrade".
> >
> > I have repeatedly heard similar complaints and would therefore prefer
> > an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> > starting with 1.7. And I have never heard anyone asking for the auto-upgrade
> > feature to be kept.
> 
> I am not against having an svn upgrade, but it seems worth noting why
> would anyone bother to report that they want you to keep a feature
> they already have?  If users are happy with auto-upgraded working
> copies, which is all we ever gave them, why would they feel the need
> to post requests to keep the feature?
> 
> We are only ever going to hear the complaints.  That does not mean
> they speak for the majority of users.

Oh, I didn't mean to imply that I'd expect people to write in
out of the blue, asking for the feature to be kept.

I meant to say that I cannot recall any user ever requesting
that auto-upgrades be kept during a discussion about whether
or not auto-upgrades should be happening or not.

Is there anyone? If so, speak up, now is your chance :)

Stefan

Re: auto-upgrade of working copy

[Mark Phippard <ma...@gmail.com>]

On Thu, Jul 1, 2010 at 5:33 AM, Stefan Sperling <st...@elego.de> wrote:
>> The auto-upgrade has always bothered me.  I'd much prefer to have a
>> command line action (e.g. "svn upgrade") to upgrade the working copy,
>> and for the default behaviour to be that the client prints an error
>> message suggesting that the user should run "svn upgrade".
>
> I have repeatedly heard similar complaints and would therefore prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> starting with 1.7. And I have never heard anyone asking for the auto-upgrade
> feature to be kept.

I am not against having an svn upgrade, but it seems worth noting why
would anyone bother to report that they want you to keep a feature
they already have?  If users are happy with auto-upgraded working
copies, which is all we ever gave them, why would they feel the need
to post requests to keep the feature?

We are only ever going to hear the complaints.  That does not mean
they speak for the majority of users.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

RE: auto-upgrade of working copy

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp@elego.de]
> Sent: donderdag 1 juli 2010 11:34
> To: Alan Barrett
> Cc: dev@subversion.apache.org
> Subject: Re: auto-upgrade of working copy
> 
> On Thu, Jul 01, 2010 at 09:25:33AM +0200, Alan Barrett wrote:
> > On Wed, 30 Jun 2010, Greg Stein wrote:
> > > Nope. Users cannot generally downgrade their client to run a
> cleanup.
> > > Historically, we have always auto-upgraded the working copies, even
> > > with stale logs in them.
> > >
> > > The 1.7 upgrade process is too invasive and time-consuming, so we
> > > decided to have a manual process ('svn upgrade'). But moving
> forward,
> > > the intent is to continue an auto-upgrade mechanism even with stale
> > > workqueues.
> >
> > The auto-upgrade has always bothered me.  I'd much prefer to have a
> > command line action (e.g. "svn upgrade") to upgrade the working copy,
> > and for the default behaviour to be that the client prints an error
> > message suggesting that the user should run "svn upgrade".
> 
> I have repeatedly heard similar complaints and would therefore prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
> starting with 1.7. And I have never heard anyone asking for the auto-
> upgrade
> feature to be kept.
> 
> The CLI client can print an error. GUI clients can show a window
> prompting
> the user whether to run an upgrade or bail out.

Hmm... and how does a client that is build/designed against 1.5, but now
linked against 1.8 handle this?

It doesn't know how to call svn_client_upgrade() as that is only introduced
in 1.7.

Possible fix: Maybe we should also enable upgrading from older variants of
svn_client_cleanup(). 
Older clients know how to call that function.

> This does not harm people using a single client much, but helps users
> who use several clients simultaneously a lot (they don't have to get
> fresh WCs to continue getting work done).
> 
> We could also add a configuration option to ~/.subversion/config that
> causes working copies to always be auto-upgraded, defaulting to 'off'.

And how does libsvn_wc (and especially the deprecated functions that don't
receive a wc_ctx) decide which config file it should use? Not all functions
receive the configuration that is read by svn and then posted in the
svn_client_ctx_t.

	Bert

RE: auto-upgrade of working copy

[Bob Archer <Bo...@amsi.com>]

> I have repeatedly heard similar complaints and would therefore
> prefer
> an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working
> copies
> starting with 1.7. And I have never heard anyone asking for the
> auto-upgrade
> feature to be kept.
> 
> The CLI client can print an error. GUI clients can show a window
> prompting
> the user whether to run an upgrade or bail out.
> 
> This does not harm people using a single client much, but helps
> users
> who use several clients simultaneously a lot (they don't have to
> get
> fresh WCs to continue getting work done).
> 
> We could also add a configuration option to ~/.subversion/config
> that
> causes working copies to always be auto-upgraded, defaulting to
> 'off'.
> 

I know this isn't a democracy, but if you are looking for votes this does seem like a more reasonable way to handle it. Especially in keeping with the goal of "not changing your data unless you tell it to" meme.

BOb

Re: auto-upgrade of working copy

[Stefan Sperling <st...@elego.de>]

On Thu, Jul 01, 2010 at 09:25:33AM +0200, Alan Barrett wrote:
> On Wed, 30 Jun 2010, Greg Stein wrote:
> > Nope. Users cannot generally downgrade their client to run a cleanup.
> > Historically, we have always auto-upgraded the working copies, even
> > with stale logs in them.
> > 
> > The 1.7 upgrade process is too invasive and time-consuming, so we
> > decided to have a manual process ('svn upgrade'). But moving forward,
> > the intent is to continue an auto-upgrade mechanism even with stale
> > workqueues.
> 
> The auto-upgrade has always bothered me.  I'd much prefer to have a
> command line action (e.g. "svn upgrade") to upgrade the working copy,
> and for the default behaviour to be that the client prints an error
> message suggesting that the user should run "svn upgrade".

I have repeatedly heard similar complaints and would therefore prefer
an explicit 'svn upgrade' upon 1.x to 1.y upgrades for working copies
starting with 1.7. And I have never heard anyone asking for the auto-upgrade
feature to be kept.

The CLI client can print an error. GUI clients can show a window prompting
the user whether to run an upgrade or bail out.

This does not harm people using a single client much, but helps users
who use several clients simultaneously a lot (they don't have to get
fresh WCs to continue getting work done).

We could also add a configuration option to ~/.subversion/config that
causes working copies to always be auto-upgraded, defaulting to 'off'.

Stefan