Re: Ignore local changes?

[Eric Siegerman]

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