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

Re: When to upgrade repository format number?

From: Greg Hudson <ghudson_at_MIT.EDU>
Date: 2005-03-12 21:04:23 CET

On Sat, 2005-03-12 at 13:15, kfogel@collab.net wrote:
> Concern for admins who downgrade across minor versions is the only
> reason to delay the automatic format upgrade until a user performs a
> locking function. If we're not going to concern ourselves with such
> admins, then there is no reason to delay the format upgrade.

I believe strongly that we should not bump the repository format number
at all. I believe the addition of locks is a compatible schema upgrade,
and the format number should only be used for incompatible upgrades. I
don't believe that "1.1 code won't honor locks" is a compelling reason
to consider 1.1 code incompatible with a 1.2 repository.

"We don't promise bidirectional compatibility across minor version
upgrades" is a dud argument to me. Users don't care what we promise;
they only care whether we deliver what they need. I think we should try
hard to provide bidirectional compatibility when we can. A certain
fraction of users uses file:/// to collaborate over a network filesystem
using FSFS, and upgrading the svn client for all users at the same time
may be burdensome to them.

If people really believe that "1.1 code won't honor locks" is a
compelling reason to consider 1.1 code incompatible with a 1.2
repository containing locks, then we should only bump the format number
when a lock is made. Only a small fraction of users will use locks, and
imposing the upgrade limitation on everyone isn't really acceptable.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 12 21:06:09 2005

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.