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

Re: We should bump WC format version number for 1.5.

From: Steve Sisak <sgs_at_codewell.com>
Date: 2007-10-05 20:48:04 CEST

At 11:24 AM -0700 10/5/07, Jack Repenning wrote:
>On Oct 5, 2007, at 10:55 AM, Ben Collins-Sussman wrote:
>>Rather than creating new flags or runtime config options, wouldn't it
>>just be simpler to prompt the user before doing an auto-upgrade? I
>>mentioned this idea earlier in the thread.
>>"WARNING: you're using a 1.5 client, and this means upgrading your
>>working copy so that it's no longer accessible by older clients. Are
>>you sure you want to proceed?"
>>This will prevent accidents happening from random user
>>'experimentation'. And it means no cryptic errors of things just
>>failing, because a user happens to have "auto-upgrade = false" in
>>their config file.
>When do you envision this prompt happening?
> a. whenever a 1.5 client is asked to do anything to a 1.4 WC
> b. whenever a 1.5 client is asked to do any write operation to a 1.4 WC
> c. whenever a 1.5 client discovers it's just about to do one of the
>write operations that actually change the format
>I think I prefer b. -- that is, the prompt happens at the beginning
>of any susceptible operation, before any changes are done, not
>half-way through the operation. "svn update --depth files *" might
>process several files (for whom "depth" is innocuous, and I believe
>unrecorded in .svn/entries) before it meets its first directory
>(where the prompt matters).

As a non-voting user (who might want to try a new version), I think
that the "principle of least user astonishment" dictates that any
command that would force an update to an incompatible format should
fail (harmlessly) with a clear message that the WC must be explicitly
updated to the new format, with instructions on how to do so.

The "Update WC" command should give the dire backward compatibility warning.

This would allow users to mix tool chains w/o risking data and make
clear which features require a destructive update.

It also allows the user to make a clear choice between new features
and backward compatibility with no surprises.

For GUI clients, you might want to follow the model of some shareware
software where some menu options are disabled and labeled as a "Pro"
feature (or in this case, not available until the WC is updated).



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 5 20:49:23 2007

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.