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

Ben Collins-Sussman <sussman@collab.net> writes:

> This isn't about conflicts,

I think it's a conflict, of sorts.

> or even about whether repository paths
> exist. It's about whether locks already exist or not. If a user
> tries to lock a repository path and there's already a lock present, an

The lock is not already present.

> error is thrown. The only way to resolve the situation is to forcibly
> destroy the pre-existing lock.

My question is when is the conflict detected:

   # lock foo/bar
   svn mkdir wc1/foo
   touch wc1/foo/bar
   svn add wc1/foo/bar
   svn lock wc1/foo/bar

   # lock foo/zig
   svn mkdir wc2/foo
   touch wc2/foo/zig
   svn add wc2/foo/zig
   svn lock wc2/foo/zig

Both foo/bar and foo/zig are locked, I don't think there is any way to
detect the "conflict" at this stage.

   # try to commit foo/bar
   svn commit wc1/foo/bar

The conflict arises if foo/bar is allowed to be committed, one might
expect it to be possible to make this commit as the the foo/bar lock
is available. However, if the commit is allowed then the foo/zig lock
gets "stranded", as it's inside a directory that cannot be committed.
I think it's a bug if this is allowed to happen.

If we allow locks on paths that don't exist in the repository then I
suggest that when adding a directory foo/ the commit has to supply all
the locks under foo/. This would mean that the above conflict is
detected when the foo/bar commit fails, and the user can resolve the
conflict by breaking the foo/zig lock, just like any other conflict.

Note that there is no conflict if foo/bar and foo/zig are both locked
in the same working copy, the client can supply both locks even if
foo/zig is not part of the commit txn.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org