In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] 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. _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs