Re: branch access control

[Mark . Hewitt]

It was my first thought to use cvs status, but this causes a
file locking
problem:

cvs status: [11:04:23] waiting for markh's lock in /tag/dcacvs/CVSROOT

I had presumed this was because the temporary file copies
(into /tmp) had to be protected from further changes while
CVS completed the commitinfo and other housekeeping tasks.
Note that this is currently using the pserver in my environment,
the situation may well be different for a local repository,
or using some other access mechanism.

#!/mjh




address@hidden wrote: -----

To: Douglas Finkle <address@hidden>
From: "Mark D. Baushke" <address@hidden>
Sent by: address@hidden
Date: 09/03/2002 06:44PM
cc: Baris Sahin <address@hidden>, address@hidden,
address@hidden
Subject: Re: branch access control

Hi Douglas,

> From: Douglas Finkle <address@hidden>
> Date: Tue, 3 Sep 2002 13:06:15 -0400
>
> Yes, you're right... you can use either of the two methods
> mentioned, 'cvs status', or the Entries file. Still, both
> of these methods are client side and their success depends
> upon software (e.g. Perl) that may or may not be present on
> client machines.

You are either mistaken or you are running a modified cvs that is not
based on the cvshome.org sources.

The URL: http://www.cvshome.org/docs/manual/cvs_18.html#SEC167 says:

| Note: when CVS is accessing a remote repository, `commitinfo' will
| be run on the _remote_ (i.e., server) side, not the client side (*note
| Remote repositories::).

> I've yet to see a good reason why a patch that passes the
> branch tag can't be incorporated into, for example, commit.c
> so the rules can be implemented completely on the server side.

Putting a 'cvs -Qn status filename' into a commitinfo log loginfo script
WILL run on the server side. It works today with versions of cvs going
back at least as far as 1.10.5 (the oldest version I had on hand to test
with for compatibility just now).

> Maybe there's more to it than I'm seeing?

It seems likely this is true.

 Enjoy!
-- Mark