[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: Mark Phippard <markphip_at_gmail.com>
Date: 2007-10-04 23:55:47 CEST

On 10/4/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> On Oct 4, 2007 12:00 PM, David Glasser <glasser@davidglasser.net> wrote:
> > * 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).
> FWIW, I agree with Jack on this - trying to educate people on
> when/why/how the upgrade happens is a lesson in futility. So +1 for
> bumping across the board whenever a 1.5 client touches the WC.

What if we held off the bump until we would be writing the WC? One of
the problems with 1.4 is anything that touched the WC rewrote it.
When you are on Windows, TortoiseSVN will eventually touch every WC on
your hard drive, depending on what you have built up in its cache and
how often you just browse your drive with Windows Explorer.

If you had to at least do an update/commit/checkout that would help a
little. Then you could at least be somewhat careful and not have it

I still maintain this is a massive problem and we should not do it. I
think a small fraction of users will ever use the depth feature and we
are pushing this problem on everyone anyway. It is going to
significantly slow adoption of 1.5 just as it slowed adoption of 1.4.
Given the growth rate of Subversion over the last year though, the
problem is just going to be magnified that much more.

Worst of all we did not raise this issue early enough that we could
make other changes we deferred to avoid a bump.

Mark Phippard
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 4 23:55:58 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.