info-cvs
[Top][All Lists]
Advanced

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

Re: CVS management of /etc - permissions problem


From: Kaz Kylheku
Subject: Re: CVS management of /etc - permissions problem
Date: Thu, 13 Sep 2001 06:25:34 GMT
User-agent: slrn/0.9.6.3 (Linux)

In article <address@hidden>,
address@hidden wrote:
>To this end I've written a script which checks in as much or as little
>of /etc's text files as you want.  And now I've found that CVS is
>getting in the way, by wiping the group and file and directory
>permissions of the files being added.  (It doesn't change the
>permissions of the files you add - but the permissions etc. in the
>archive seem to owe more to your umask than to the file.  So, for
>example, /etc/passwd would be readable by everybody, or /etc/profile
>might not be readable by anyone except root.)

This kind of problem is a symptom of confusing the working copy of
the artifacts in CVS for the deployed objects based on those artifacts
which are actually released into to production use.

CVS is not a build system for constructing the contents of your
UNIX system's /etc directory, nor any other software structure.

It's a version control system with which you can manage some *alternate
representation* of the artifacts in /etc, based purely on text files.
Or of any other type of software you wish.

That alternate representation should be capable of generating,
or undergoing generation to, a production /etc directory.

To that end, the versioned representation can contain auxiliary materials:
not only text files that appear under /etc/ but also a script which moves
files into place and sets up permissions.

This separation of representations gives you more control and freedom.
You can control file permissions as versioned artifacts, since they
are recorded as permission-setting commands in a script that is
itself versioned.  You can control file locations as versioned artifacts,
since they are recorded as copying commands in a script. You can write
programs which generate files instead of writing the files themselves,
or use macro processing to generate files.

So you see, it's a fundamental misconception that the conventional
metadata on the CVS version files is actually part of the versioned
content. The ownership and permission of a ,v file in the repository,
or of a checked out copy, are completely irrelevant. If you want
something to be versioned, you have to capture it in a file
representation, and make sure that file is versioned under CVS.


reply via email to

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