On Feb 3, 2005, at 10:46 AM, Philip Martin wrote:
>
> # 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
Do you mean 'svn commit wc1' here? I think commit will choke if you
try to commit a target whose parent is scheduled for addition. You'd
have to commit both foo and 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.
There's nothing wrong with locks being 'stranded' (or 'made defunct',
is the terminology we use in the locking spec.) It's no different than
somebody forcibly breaking a lock. The whole token-in-wc design
assumes that a token can become defunct at any time. 'svn up' will
remove defunct tokens.
So I'm not sure if there's really a problem here.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 3 19:21:20 2005