Re: Why can't root check in files?

[Kaz Kylheku]

In article <address@hidden>,
address@hidden wrote:
>First off, I should thank everyone who's taken the trouble to discuss
>this.  I should also say that the reason I'm still discussing it at
>length is not because I'm trying to do something childish like "win an
>argument".  I really am simply concerned that maybe there's a major
>flaw in my approach, and wanting to find out what it might be.

There is a flaw in any approach to using CVS which views the working
sandbox as the deliverable object. This is not how CVS is used in ``ordinary''
software development, and it's not really the way it can be used for
other purposes, like maintaining the software in your /etc directory,
managing web pages or whatever.

The structure that is versioned in CVS should be seen as a set of inputs
which produces the deliverable thing.

Not every file in the inputs will necessarily correspond to a unique
deliverable object.  For example, a C project may have many .c files,
yet the deliverable is one executable.

There are reasons not to treat /etc as your working sandbox, in addition
to the cited reasons related to avoiding system screwup or security
problems:

- There are machine-specific variables in /etc, such as the system's host
name. If these are not created by a special step, but rather stored in
CVS directly, then you can't reuse the configuration for multiple machines.
You may want some centralized way to specify all the variables that
make up a machine configuration, and then in the generation step,
disperse this information into the right places. You might not care
about this today, but you might tomorrow. What if a friend wants to use
your funky version-controllable system configuration scheme?

- You may want to write scripts which generate some of the /etc content,
or use macro preprocessing.  By doing this, there won't be a 1:1
correspondence between the repository files and /etc files. It's
inappropriate to pollute an actual /etc directory with these
extra source files.

- The files in /etc have important attributes besides their content,
like permissions and ownership.  Changes to these can't be tracked in
CVS. However, your ``build'' scripts which generate /etc can set up these
permissions, and those scripts can be versioned. So you can track this
information indirectly.

- You may want a different directory layout for your repository
versus the running /etc.  There is no reason why the two structures
should be identical. For example, if I were doing this, I might
make everything flat, just for the sake of convenience. Or organize
things into directories according to function.