"David Glasser" <email@example.com> 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.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Oct 4 21:16:26 2007