[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lockinfo
From: |
Kendy Kutzner |
Subject: |
Re: lockinfo |
Date: |
Mon, 9 May 2005 18:25:46 +0200 |
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
- lockinfo, Kendy Kutzner, 2005/05/06
- Re: lockinfo, Mark D. Baushke, 2005/05/06
- Re: lockinfo,
Kendy Kutzner <=