Having gone through the extreme pain of upgrading 2000 users in a
corporate environment from 1.3 to 1.4 and seeing
many have multiple incompatible clients installed, I'll take anything that
makes it less painful. We even have projects
that are forced to use certain versions due to environment lock downs or
contract agreements. If one person
is working on 2 projects requiring different versions things get very
messy.
We need to remember there are more and more "nontechnical" users of
subversion and most don't have
a clue that a new version of TortoiseSVN might have automatically upgraded
something just by clicking
in explorer.
In a perfect world, the formats would be forward AND backwards compatible.
I.E. old clients would preserve
(and ignore) any new data they did not understand, and new clients would
add new data (with default values) if
it wasn't present.
I can dream, right?
Kevin Radke
Karl Fogel <kfogel@red-bean.com>
10/04/2007 11:16 PM
Please respond to
Karl Fogel <kfogel@red-bean.com>
To
"David Glasser" <glasser@davidglasser.net>
cc
"Mark Phippard" <markphip@gmail.com>, "Jack Repenning"
<jrepenning@collab.net>, "Erik Huelsmann" <ehuels@gmail.com>, "Ben
Collins-Sussman" <sussman@red-bean.com>, dev@subversion.tigris.org
Subject
Re: We should bump WC format version number for 1.5.
"David Glasser" <glasser@davidglasser.net> writes:
> Let me try to summarize the current discussion:
>
> I think we all agree on:
>
> * We can't store a non-infinite depth in an entries file of a format
> that a 1.4 client can write, because that can read to corruption, so
> *at the very least* any entries file with non-infinite depth *must*
> have a new format (9).
>
> * wc format upgrades are a pain for users who are using multiple tools
> or computers to access their wcs.
>
> There are two solutions: make 1.5 upgrade all entries files to 9, or
> only those with non-infinite depth. (As usual there will be a #define
> to prevent *any* upgrading.)
>
> The advantage to the former is simplicity: it is easier for a tool
> author (for example) to say "as soon as you use the new version you
> will need to upgrade your other tools" than something more nuanced
> like "as soon as you use the new version and use depth features, you
> will need to upgrade your other tools".
>
> The advantage to the latter is that users who don't use the depth
> features can happily use 1.4 and 1.5 tools together on the same
> working copy, making the upgrade much smoother... as long as they
> don't use --depth.
This summary is accurate. I think what Jack is trying to get at is
that the latter behavior is much less predictable and less
comprehensible than the former.
Users might at least not feel cheated when their working copy becomes
un-useable with 1.4 after they touch it with a 1.5 client. Annoyed,
yes, but many would understand: "Oh, the new version upgraded my
files, now I can't downgrade. Sigh, okay."
But with the latter behavior, they might use 1.4 and 1.5 clients
interchangeably for a year, and *then* someone would try out --depth,
and suddenly that working copy would become unuseable for 1.4 clients.
"What the heck? We haven't changed our Subversion installation in a
year! Why did this happen? We didn't change anything, *no fair*!"
There are degrees of unawareness. People are very unlikely to think
of trying depth features as "an event", whereas at least some people
will remember vaguely that they did an upgrade at one point.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 4 21:46:27 2007