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

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
exists.

> 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