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

Re: locking a file renders repos unusable with older clients

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-03-27 20:31:43 CEST

On Mar 26, 2005, at 11:22 AM, Greg Hudson wrote:
> Disable locking by default in 1.2. Turning on locking implies a format
> bump. "svnadmin create" can (by default) continue to create
> 1.1-compatible repositories.
> The exact mechanism for turning on locking could vary. It could be an
> svnadmin command, or a manual edit of a repos config file (which we'd
> have to introduce, it looks like). "svnadmin create" could have a flag
> to create a repository with locking enabled, of course.

Woo, a popular revolt!

This was kfogel's baby, so I'm patiently waiting for him to return to
work next week and help resolve this issue.

Talking with mbk on irc, I think we need to keep perspective here. I
agree that our current trunk code won't cut it. I think we have two

   1. require a deliberate upgrade switch, as ghudson and maxb have
suggested, or

   2. just punt completely.

Remember that our decision most likely affects setups of many clients
accessing FSFS over file:///, mostly likely on an NFS share or
something. I suspect this is not so uncommon.

In that scenario, it comes down to deciding which is the lesser of two

   * is it worse for one client to lock something over file:///, and an
older client to accidentally ignore the lock?

   * or is it worse for the admin to say "I'm enabling locking now, all
clients *must* upgrade to 1.2."


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 27 20:33:02 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.