[Top][All Lists]

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

Re: to stop commit

From: Mark O'Brien
Subject: Re: to stop commit
Date: Fri, 19 Aug 2005 07:46:03 -0400

On 8/18/05, Mark D. Baushke <address@hidden> wrote:
> That said, there are pragmatic reasons why the CVS team has not tried to
> remove the :pserver: support from CVS. Many folks would not be able to
> get other enhancements and updates if we stopped supporting their
> current setup. I do wish we could remove support and strongly urge you
> to move away from :pserver: use if at all possible.

I actually would like to move away from pserver, however I would need
a setup for cvs ssh access that respects a readers and writers
concept. Where cvs can specify which users can read and write in which
repositories. If this happens, then all I would need is a cvs binary
that is wrapped to run as a common OS group.

Trying to maintain independent unix groups to manage read and write
access in each directory inside repository structures would be a
nightmare in our setup. Not just on the cvs side, but the user id
side. The pserver allows us to setup an individual passwd file for
each repo, which provides read access to that repo, and the writers
file which lists which passwd ids also have write access. No one has
unix access read/write to the cvs repository filesystem in our setup,
only the pserver account and the admin accout (only account permitt to
access via :local: method)

I don't completely subscribe to the rationale that controlling who can
perform what functions in within a toolset (such as cvs
checkout/commit) should be managed by OS file permissions inside a
code repository. The fact CVS's particular repository implementation
can somewhat do this by setting up OS file permission manually by hand
directly in the repository (which I think is a bad thing, personally
thinking nothing should be done outside of cvs commands to the cvs
repositories as a standard policy) does not give weight to that

How have people implemented branch access controls in cvs? Via scripts
using ids, not by OS file permissions. How does the cvs admin
subcommand itselft control access to its functions, not by OS file
permissions, by an OS id (yes, a group id, on a tangent... but I this
it would be better to have admin access by OS id instead of OS group
and be able to setup lists per repo).

If you want to make pserver obsolete, you need to provide the
features/functions it provides to the access methods you would prefer
eveyone to use/move to.


reply via email to

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