Re: lockinfo

[Kendy Kutzner]

Hi Mark,

On 2005-05-06T09:09:37-0700, Mark D. Baushke wrote:
> To be considered for inclusion in a CVS FEATURE release, you should
> provide changes to the doc/cvs.texinfo

attached

> as well as at least a few test
> cases (if you don't understand how to work with sanity.sh that is okay,
> but we need a series of step-by-step commands that illustrate how to
> verify that everything works with your new feature and how the new
> feature interacts with existing features).

I didn't get everything from sanity.sh, but here are some ideas for test
cases:

- 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)
- checkout c should work

> For this particular addition, I have a problem with how it works.
> 
> Assumption: I have a repository where there exists one directory called
> Private that is 'read-locked' such that userA is able to checkout
> directory Private and userB is not.
> 
> If userB starts a 'cvs checkout -d top .' command. What should you
> expect to happen:
> 
>   a) no files are checked out because Private will fail and that
>      'should' stop the checkout command from providing partial
>      information.
> 
>   b) all directories that are processed up to, but not including the
>      Private directory are checked out. However, any files that
>      would logically have been checked out of directories after
>      "Private" are not checked out because the directory traversal
>      will stop when "Private" is first reached.
> 
>   c) all directories other than "Private" will be checked out of the
>      repository and the user will receive a "Lock Info failed" message
>      that they may or may not notice indicating that the "Private"
>      directory was not checked out.
> 
> With your current patch, I believe userB will observe behavior 'b',
> but I am not sure if that is true or not.

As I see it, you are right, it should be 'b'.

> It is not clear to me if behavior 'a' or behavior 'c' is the correct
> behavior, but I believe behavior 'b' is not desirable.

I see your worries. But i think that's the way CVS works:
directory-by-directory. There is no commit-atomicity, there is no
lock-atomicity. I think the behaviour is comparable to a scenario where
userB does not have (file-system) write permissions to the directory.

I added the solicited changes to cvs.texinfo as well as new changes to
src/mkmodules.c to create a default version of lockinfo.

Kendy

--

cvs.lock_info.patch
Description: Text document