[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 21:09:29 CEST

On 10/4/07, David Glasser <glasser@davidglasser.net> wrote:
> 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.

Keep in mind that most people that use Windows install TortoiseSVN.
Because of the way it works, your WC will be touched sooner or later
by it whether you mean it or not. This is what happened with 1.4.
Mac users of SCPlugin would have the same issue.

Command line users can control this a lot easier than GUI users can.
That is why I think deferring the update until --depth is used is

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 21:09:38 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.