freebsd stable - Apr 2004 - Can I maintain config files as a CVS branch w/o messing up mergemaster etc.?

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.


-- 
Doug Lee           dgl@dlee.org        http://www.dlee.org
Bartimaeus Group   doug@bartsite.com   http://www.bartsite.com
"Pray devoutly, but hammer stoutly."
--Sir William G. Benham

* Doug Lee <dgl@dlee.org> [20040429 23:59]:
> Comments and ideas welcome.  Please Cc me if that's ok.
/usr/ports/sysutils/etcmerge

I don't use it (yet), but have thought about it. Please report back
(even privately) on usage if it works for you.

qvb
--
pica

>Date: Thu, 29 Apr 2004 17:59:18 -0400
>From: Doug Lee <dgl@dlee.org>
>To: freebsd-stable@freebsd.org
>Subject: Can I maintain config files as a CVS branch w/o messing up
>Sender: owner-freebsd-stable@freebsd.org
>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).
I also track -STABLE (as well as -CURRENT); however, my approach is to
go ahead and maintain a private mirror of the CVS repo.  (Actually, I do
this on a couple of boxen, one of which is my laptop.  The CVS repo on
my laptop is thus actually a mirror of my private mirror.)

Disk space is not all that expensive nowadays; the repo appears to take
right around 2 GB:

g1-15(4.10-P)[1] cd /cvs/freebsd/
g1-15(4.10-P)[2] du -ks .
2084040 .
g1-15(4.10-P)[3] 

And I find it handy to have the repo on my laptop.  (I run a Web server
on it, too, so I can play with cvsweb locally, even if I'm disconnected
from the Net.)

>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:
Yes, well....  I could be wrong about this, but I would expect that
having different files in the same (CVS working) directory have their
histories &c. in different CVS repositories would be awkward, at best.
After all, a given directory may have at most one "CVS" subdirectory.

That said, I do this sort of thing for /usr/src/sys/i386/conf:  the
original files I leave alone; my working kernel config files are merely
represented by symlinks (in my case, to /usr/local/src/kernels/...), and
the latter hierarchy is in a local CVS repository (parallel to the
FreeBSD one).  (Source control is A Good Thing.)
>    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
Along with the above, I use mergemaster.

Frankly, after doing this for over 2.5 years (tracking each of -STABLE
and -CURRENT on a daily basis, missing a total of maybe a dozen days in
that time for -STABLE; perhaps twice that for -CURRENT), I find it
rather simple and straightforward.  I would be hard-pressed to come up
with a reason for wanting to find a different approach.  (My build
machine -- which is presently powered off -- has built something along
the order of the 875th iteration of its -STABLE kernel since /usr/obj
was last cleared.  The laptop's numbers are considerably smaller, as I
needed to replace the disk drive a few months ago.  And -CURRENT tends
to need clearing /usr/obj a bit more often than -STABLE does.  :-})

Peace,
david
-- 
David H. Wolfskill				david@catwhisker.org
I do not "unsubscribe" from email "services" to which I have
not explicitly
subscribed.  Rather, I block spammers' access to SMTP servers I control,
and encourage others who are in a position to do so to do likewise.

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