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

Re: Locking: RFC: svn:needs-lock behaviors (Updated)

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-02-03 21:03:27 CET

On Feb 3, 2005, at 12:54 PM, Philip Martin wrote:

> Whether the commit breaks the foo/zig lock, or whether the lock
> remains but is unuseable, it looks like a problem to me. It's a
> problem because the user making the commit doesn't know about the
> foo/zig lock,

Not necessarily true. If they run 'svn st -u', they'll see that it

> they are unaware that it exists before the commit and
> they don't know that the commit has stranded or broken it.

You seem to be bothered by the idea that a lock might be stranded in
the repository... that the user who created it will abandon the token,
or that the repository lock will sit and rot for ages. But I doubt
that will be a problem in practice. 'svn st -u' will show that lock
(so will 'svnadmin lslocks'), and eventually somebody will notice it
and just kill it.

> That sort
> of inadvertent behaviour is exactly what locking is supposed to
> prevent, isn't it?

Well, not really. Locking is supposed to prevent people from wasting
time in writing unmergeable changes.

> Far better to force the user to explicitly break
> the lock before allowing the commit.

So your proposal is that when a new directory is added to a commit-txn,
the filesystem should require token-authn for all locks that exist
below the path, yes? (And of course, the locks would all be on
nonexistent paths.)

Good news, the fs is already doing this. Look at
libsvn_fs_base/tree.c:2864 in the locking branch. I assume
libsvn_fs_fs is doing the same. (fitz?)

So, maybe there's nothing to argue about, then? :-)

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 3 21:06:21 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.