Re: lockinfo

[Kendy Kutzner]

On 2005-05-09T11:25:06-0700, Mark D. Baushke wrote:
> > - empty/nonexistent lockinfo: everything should work as ever
> > - layout $CVSROOT/a, $CVSROOT/a/b, $CVSROOT/c
> > - lockinfo contains
> >     ^a false
> >     ^a/b true
> > - checkout a should fail
> > - checkout b should work (i'm not too sure)
> 
> I believe CVS processes directories alphabetically depth-first. So, in
> this case, b would also fail unless you explicitly did a
> 
>      cvs checkout a/b

you are right, that's what i'm talking about when i wrote 'checkout b'

> In point of fact, the addition of this new feature may be a good time to
> alter how cvs works.

as long as i don't have to write it :)

> If you are explicitly controlling checkout
> behavior, then you could choose to non-fatally skip directories for
> which you do not have permissions... it would be as if they were really
> private to some other set of users and not even visible to the user
> implicitly trying to check them out.

Than CVS internals really have to be changed. My little patch makes the
lock creation fail. When lock creation fails, CVS aborts the current
operation. One possible change: first lock all directories which are
going to be used. If all locks were successfully created, do the
checkout: somehow
        if (start_recursion(lock..)){
                start_recursion(checkout..)
                start_recursion(unlock..)
        }

> Although it may be desirable to
> force an error if the user explictly asked for a 'read-locked' directory
> on the command line instead of just running into one during the checkout
> process.

But as I said, that's exactly the behaviour when someone enforces 'dont
read (dont create locks)' with file system permissions.

> Addition of this kind of 'read-lock' might be considered to be 'better'
> than just use operating-system directory permissions.

It's not that elegant, but more flexible. And it works with all kinds of
file systems.

> I still remain unconvinced that the current implementation of your patch
> is desirable.

Since my patch is GPL, everyone is free to change it / ignore it. In
which direction do you would change it?

> > +Before the lock is created, the @file{loginfo} in CVSROOT is
> The above line references `loginfo' instad of `lockinfo' which seems
> wrong.

Because it is wrong :)
But I think I don't need to send a patch for that :)

> I suspect that some mention that this is for read-locks instead of
> dealing with promotable or write locks...

I thought write locks are an entire different ball game? But feel free
to correct me.

> it also begs the question as to the correct name for this file being
> 'readinfo' instead of 'lockinfo' ...

As I wrote, anybody can change that.

Kendy

--

pgpS0M5mha4Hi.pgp
Description: PGP signature