Ben Collins-Sussman <sussman@collab.net> writes:
>> 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.
I was assuming that foo/zig would remain locked as it is not involved
in the commit txn, so the repository would still have a lock on a path
that does not yet exist, the wc would still hold the lock token, but
the token would be under a directory that cannot be committed because
it would be a conflict. I suppose the repository could break the
lock, but I don't like that design any better.
> The whole token-in-wc design
> assumes that a token can become defunct at any time. 'svn up' will
> remove defunct tokens.
'svn up' is going to generate a conflict on 'foo', I suspect the user
will abandon the directory and the lock token.
> So I'm not sure if there's really a problem here.
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, they are unaware that it exists before the commit and
they don't know that the commit has stranded or broken it. That sort
of inadvertent behaviour is exactly what locking is supposed to
prevent, isn't it? Far better to force the user to explicitly break
the lock before allowing the commit.
--
Philip Martin
---------------------------------------------------------------------
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:55:42 2005