On Wed, Apr 02, 2003 at 01:09:44PM -0500, Todd Denniston wrote:
> if on the third hand (hey, where'd that come from?) each engineer needs their
> own config that does not change often and it for some reason can not be tweaked
> to the specific setup by a build script <probably_bad_suggestion>you could each
> branch your version of the config file and not worry about the fact that it is
> under version control</probably_bad_suggestion>.
In this case, I typically make several files, and CVS-track those:
httpd.conf-ERIC
httpd.conf-SHIRLEY
Or, back when CVS had options.h.in:
options.h.in-FREEBSD
options.h.in-LINUX
options.h.in-SOLARIS
What happens next depends on circumstances:
- In both of the above examples, each sandbox then symlinks the
appropriate variant into the working location. If it's a
third-party package, I still CVS-track the un-suffixed "real"
file -- "httpd.conf" or whatever -- but only for vendor
updates and for local changes that should apply to all
sandboxes.
The trick I just posted about would be useful here -- setting
a sticky revision tag on the "real" file to prevent
accidental commits. I'll have to try that myself the next
time the issue comes up :-)
- Sometimes, the per-user files aren't hand-edited copies of
the "real" file, but instead contain parameters to be
substituted into a generic template. In that case, no
symlink is made, but people (or the build system) have to
rerun the template-substituter when the template or a user's
per-sandbox parameters file has changed.
--
| | /\
|-_|/ > Eric Siegerman, Toronto, Ont. [EMAIL PROTECTED]
| | /
A distributed system is one on which I cannot get any work done,
because a machine I have never heard of has crashed.
- Leslie Lamport
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
