Re: locking a file renders repos unusable with older clients

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
options:

   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
evils:

   * 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