Re: Synergy

[Chip Norkus <wd@xxxxxxxx>]

On Saturday 02 August 2003 09:41 pm, Matthew D. Fuller wrote:
>
> The 'easy' answer to this is to have a mergemaster-like tool that
> understands CVS.
>
> Thus, if I change (for instance) root's GECOS info, or shell, or
> homedir, the tool can pull out the revision I started with and the
> current revision, compare those diffs with my diffs, and say "Hm, well,
> this line is different in the working copy from the original...  but
> the current version is no different than the original, so that must be
> a user change I should preserve".  Or the similar step of diff'ing the
> working copy against the original revision is started from, checking
> out the current, then applying those user changes to the new version.
>

The only problem I have with this is that it ties you to CVS.  I've 
recently started making the switch from CVS to Subversion in my own 
projects for a variety of reasons, and I've been kicking myself because 
of the things I used in my code which were very dependent on the quirks 
of CVS (build scripts and stuff like that).

What you could do, instead, is to keep a copy (or maybe just the sum) of a 
pristine copy of the config file when you install a package.  This works 
best as example, so let's say you do the following:

1) Install your system.  Part of your system is the 'passwd' package which
   comes with stuff like the pw util, ch* utils, /etc/passwd and
   /etc/group files, and maybe some other stuff.  When the package gets
   installed it stores some kind of snapshot of /etc/group and /etc/passwd
   (maybe just an md5 sum, maybe an actual copy of the file).
2) You add some users to your passwd file.  The package system now knows
   that you have modified your copy of /etc/passwd
3) Update the passwd package (which maybe comes with an update to a basic
   user account).  Now depending on how much your packaging system did to
   remember the contents of the pristine passwd file it can say:
   a) You've modified the file.  I don't know how you did it, so what I'd
      like for you to do is go through this mergemaster-esque process to
      help me set things in order.
   b) You've modified this file, and I know what you did.  I can merge in
      these system changes without your aid.  All done!

And maybe if this was a particularly smart or configurable program you 
could tell it, before it starts installing packages, which behavior you'd 
prefer.

>
> The difficulty with such schemes is that you either need to have the
> full CVS repo around, or you need to create something like
> /var/backups/etc with ALL the files in their untouched form, to use for
> comparison against.  Then you need to keep that directory updated.  It
> raises the bar a *LOT* for people using the program.
>

Yeah.  Trying to use cvs is a bad idea I think for a few reasons.  Right 
now the preferred time to run mergemaster is in single user during the 
midpoint of a world-ugprade.  This is about the worst time to ask someone 
for cvs connectivity, and people are not going to want to keep even part 
of a cvs tree around and updated.  I think the best way to do this is to 
make this kind of behavior optional, down to a per-package level.

> Now, having such a thing for differences between explicit versions is
> relatively easy, since you could in some manner compile all that
> knowledge into it.  But for the BSD Way (tm) of building and upgrading
> the world at arbitrary points along a CVS branch, you couldn't
> realistically have that kind of info available, without having a CVS
> repository also available.

Yes, this is where it gets tricky.  When people update their world (base 
system) outside of the realm of the packaging tool.  I think if that is 
going to continue being supported (and it should be) then what ought to 
happen is that the packaging tool should become an integral part of the 
world installation.  So when you update your world, what you're actually 
doing is building from source all the base system packages and then 
having the package manager dist them out.  One of the nice things this 
gets you is that the package manager can nerf obsolte files from replaced 
packages and walk you through the merge as an explicit part of the build 
process, instead of acting as an optional component like mergemaster.

-wd
-- 
chip norkus; renaissance hacker;                wd@xxxxxxxx
"question = (to) ? be : !be;" --Shakespeare     http://telekinesis.org/