[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: branch access control

From: Mark . Hewitt
Subject: Re: branch access control
Date: Wed, 4 Sep 2002 04:30:51 -0500

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

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.


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,
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 sources.

The URL: 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.

-- Mark

reply via email to

[Prev in Thread] Current Thread [Next in Thread]