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

Re: [Locking] commits and unlock (revisited)

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-02-23 11:44:31 CET

Jack, the bulk of your discussion of use cases is very useful, but I think you
introduced some confusion over the phrase, "the need for a lock is a property
of the [change|file]". You are talking about a logical, conceptual property,
not meta-data. Both ways are supported by Subversion locks and
"svn:needs-lock" (which is a meta-data Property of the file).

In your conclusion:

Jack Repenning wrote:
> The upshot I recall was (keyed to your alternatives):
> (a) This is the "the need for lock is a property of the change" model.
> Unfortunately, we can't do it well (due to lack of preexisting
> always-(well-nearly)-required please-let-me-edit step). Let's sigh a
> small sigh and not do this.

Let's not do what, exactly?

We can cater for lock-during-change well enough, using "svn:needs-lock" to help
users notice that a lock is needed and "svn lock" to reserve a file and some
form of "svn commit" (possibly with "svn unlock") to finish with it. OK, it's
not as neat as in systems that inherently work like this, but it's not too bad
given that it has to fit in to Subversion's flexible development model.

> (b) Insanity.

That conclusion is based on lack of information - not your fault. In fact (b)
- unlocking only the files that have changed - is a reasonable alternative to
(a), but I believe the consensus is that it is inferior to (a).

> (c) This is the "the need for lock is a property of the file" model. We

... by which you mean a long-term lock, not just existing while a change is
made. Certainly option (c) - "commit" never unlocks (by default) - fits this
case well.

> can do this well. It covers the most-often cited use cases (files whose
> data cannot be merged, and users whose minds cannot grasp merge). Let's
> do this one.

It does cover those cases, but (a) covers them with fewer steps or options to
remember.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 23 11:45:43 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.