Date: Sat, 1 May 2004 12:23:15 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Doug Lee <dgl@dlee.org>, freebsd-stable@freebsd.org Subject: Re: Can I maintain config files as a CVS branch w/o messing up mergemaster etc.? Message-ID: <p06020400bcb978085077@[128.113.24.47]> In-Reply-To: <20040429215917.GZ55912@kirk.dlee.org> References: <20040429215917.GZ55912@kirk.dlee.org>
next in thread | previous in thread | raw e-mail | index | archive | help
At 5:59 PM -0400 4/29/04, Doug Lee wrote:
>I track STABLE and wonder if there's a clean way for me to use
>CVS to do it (without having the whole CVS repo on my box).
>Example: I modify /etc/rc.firewall and then cvsup my way up
>to a more current STABLE. The normal tactic is to hand-merge
>via mergemaster, but I think there should be a way for me to
>get CVS to do it:
>
> cvsup/mergemaster for fresh system (hypothetical of
> course) (current /etc/rc.firewall is now exactly
> the STABLE version)
> make local mods
> cvs commit mods (locally)
> cvsup
> use CVS instead of Mergemaster to merge in changes since
> last cvsup
>
>Problems:
>
>1. FreeBSD itself uses CVS, so I don't think I can just create
> a repo of my config files and pull in cvsups as a vendor
> branch.
>
>2. Mergemaster (which might still be useful alongside this
> sometimes) uses CVS Id strings to notice when a file hasn't
> really changed in the main FreeBSD repository, so even if I
> do start managing my config files by CVS despite the above
> issue, I think I'd be making mergemaster throw a lot more
> stuff at me to do myself.
>
>Comments and ideas welcome. Please Cc me if that's ok.
I do not think this will work out well.
I have some half-formed ideas which might address the goal here,
and those ideas go something like this:
When mergemaster-ing, what I'm usually doing is changing one or
two specific lines. This is not great for standard CVS to track,
because CVS wants to track "the context" of the change. For
instance, let's say in /etc/ssh/sshd_config I want to change the
port that sshd runs at. All *I* really care about is that the
line:
#Port 22
should change to:
Port 2222
For many of my changes, I know that the line I'm changing is going
to occur exactly once in the file. But if you use CVS to track
that change, you're going to hit "conflicts" if the base system
changes that line, or any of the three lines before or after the
line you care about. That's because CVS wants to match the context
of the line, and not just the line itself. Imagine how annoying
this gets if the line that you care about is two lines after the
$FreeBSD$ line... It (cvs) will also be looking for exact-matches,
which is frustrating when people keep making white-space changes
(which happens all too often with the GENERIC kernel, for instance).
So, my idea is to write up some sort of script which knows a little
more about the specific formats of a file. I use that to say 'if
you find this SPECIFIC line (ignoring whitespace), then replace
that specific line with "Port 2222"'. In the case of inetd.conf,
the processing is more like 'If you find this specific line, then
change the first field to be "ftp" (instead of "#ftp"), and tack
on a "-S" to the end of the line.
Once you have that script, then you combine it with the
MM_PRE_COMPARE_SCRIPT
option that you can set in ~/.mergemasterrc.
The way this works is that mergemaster starts up, and creates a
"distributed-system version" of what should be in /etc. Before
it starts comparing that version (in /var/tmp/temproot/etc) to
the real /etc on your system, it runs your script. So, you have
your script modify the files in /var/tmp/temproot/etc.
After your script finishes, mergemaster starts comparing that
directory, as you have modified it, to your base-system directory.
(so don't go changing any $FreeBSD$ lines!). If mergemaster finds
something which has changed, it will be installing the file that
you have already updated.
I use this tactic for a few files. Note that your script might
make *its* decisions based on what is presently in /etc. So I
have one script which runs on all my machines, and the value for
"Port" in sshd_config is only changed on some of those machines.
I think this tactic is usable for many config files, but what I
have done is limited to just the few files which I care about.
It does require a little extra setup, but it has helped to make
mergemaster-ing much nicer for me. And if you have this script,
you can always put *that* in your own CVS repository, since that
script is not part of the FreeBSD repository.
--
Garance Alistair Drosehn = gad@gilead.netel.rpi.edu
Senior Systems Programmer or gad@freebsd.org
Rensselaer Polytechnic Institute or drosih@rpi.edu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p06020400bcb978085077>