[Top][All Lists]

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

RE: Per-modules readers/writers ?

From: Greg A. Woods
Subject: RE: Per-modules readers/writers ?
Date: Mon, 28 Oct 2002 19:19:58 -0500 (EST)

[ On Monday, October 28, 2002 at 13:44:50 (-0800), Shankar Unni wrote: ]
> Subject: RE: Per-modules readers/writers ?
> This makes it hard for the repository administrator to put in a level of
> access control without having to spend days or months running after the
> other departments, and genuflecting in front of the change review
> boards.

Version control is a part of software configuration and change
management.  I thought that (what you said) is what it (change
management) was all about!  ;-)

> Other competitive source-code control systems have such informal
> mechanisms in place that are trivial to administer, _for the person who
> is responsible for maintaining the repository_, and it's generally in
> response to overwhelming customer demand.

I think you're still missing the point.  CVS is a _very_ _simple_
version control tool that is built entirely upon RCS and it does very
little on its own except make some repetitive tasks easier, and provides
some hooks where various procedures can be integrated into these tasks.
RCS uses normal Unix files and filesystem protections, providing only
for directory level access control through the normal underlying
filesystem access controls of who can read (and search in) a directory
and who can write to that directory.  There's no access control
possible, not even theoretically, for any of the internal structure of
an RCS file -- anyone who can write to the directory containing the file
can change any content of the file.

Those other "competitive" (*) source code control systems are either
promising things they simply cannot possibly deliver securely, or they
have fundamentally different underlying repository designs.

(*) open source tools like CVS do not compete for market share and their
    developers and maintainers have very little incentive to provide
    features which "customers" demand if those same features are not
    also directly of use to the developers and maintainers, especially
    when such features demand a ground-up re-design of the whole thing.

    If you think some so-called "competitive" tool is better suited for
    your requirements then you really should use it instead of CVS --
    CVS isn't meant to be the one tool that meets everyone's needs!

    Even if you paid someone (such as myself ;-) to re-design and
    develop a variant of CVS to make it do what you want it to there's
    no guarantee that it would replace CVS or even be embraced by other
    CVS users.

                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>

reply via email to

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