[svk-devel] Re: a few locking-related issues

[David Glasser]

On 8/18/06, David Glasser <glasser at mit.edu> wrote:
> I have a patch that attempts to deal with the two above points. Key changes:
>
> * XD->_store_config dies if the giant lock is not held.  I'd recommend
> that folks apply just this addition and then try things like making
> two separate checkouts and running "svk mkdir checkout1/foo
> checkout2/bar", noticing that this blows up, and getting scared.
>
> * XD->lock no longer stores config and un-giant-locks.
>
> * XD->giant_lock doesn't unlock (deleting the file) unless it thinks
> it holds the lock.
>
> * $cmd->run_command explicitly calls store instead of giant_unlock
> after calling $cmd->lock.

I've finally applied this patch, along with using Fcntl for actual
locking of the lockfile, in r1927.  (I'd really appreciate Windows
testing, to the degree that trunk works on Windows at all!)
I still have not dealt with this issue:

> > (d) Several commands lock a condensed (arg_condensed or
> > target_condensed) version of the arguments.  Let's say that you have
> > checkouts at /path/a and /path/b and you use one of these commands on
> > files inside both checkouts at the same time; locking the condensed
> > argument will place the lock on /path (which is not inside any
> > checkout!)
> >
> > First, I'm not sure if this in and of itself should be considered a
> > problem. Even if it isn't, though, it means that the idiom used in
> > several places of
> >
> >         my ($cinfo, $coroot) = $self->{checkout}->get ($copath);
> >
> > is flawed: $coroot here can end up with a datapoint that just contains
> > a lock entry and not an actual checkout at all! I haven't quite
> > managed to make this give me an obvious bug, but in playing around
> > with commands which use condensed arguments I have had a bit of odd
> > behavior which I think is related; I'll try to get more details later.

--dave

-- 
David Glasser | glasser at mit.edu | http://www.davidglasser.net/