[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ignore local changes?
From: |
Eric Siegerman |
Subject: |
Re: Ignore local changes? |
Date: |
Wed, 2 Apr 2003 14:49:55 -0500 |
User-agent: |
Mutt/1.2.5i |
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. address@hidden
| | /
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