-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark D. Baushke wrote:
> I honestly don't know if it is a good idea to
> introduce this patch to feature in this way at
> this time.
>
> What do the other maintainers think of this kind
> of extension?
I don't have a strong opinion either way. Some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kendy Kutzner <[EMAIL PROTECTED]> writes:
> 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/
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
>
r 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/
at 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/n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Kendy,
To be considered for inclusion in a CVS FEATURE release, you should
provide changes to the doc/cvs.texinfo 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
Attached is a patch to current release which introduces a file
$CVSROOT/lockinfo. The file has the same properties as other *info files
in that directory.
Intended usage: Directories are read-locked before any read-operation is
done. A script (along the lines of contrib/cvs_acl.pl) can check