DragonFly BSD
DragonFly kernel List (threaded) for 2003-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Synergy

From: "Matthew D. Fuller" <fullermd@xxxxxxxxxxxxxxx>
Date: Sat, 2 Aug 2003 22:50:34 -0500

On Sat, Aug 02, 2003 at 10:27:03PM -0500 I heard the voice of
Chip Norkus, and lo! it spake thus:
> 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.
> >
> > [...]
> >
> 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).

Oh, quite true.  Wherever I wrote "CVS", instead substitude "whatever
revision control the system is under".  But then you have to make sure
your merging tool knows what that is, how to access it...   heck, maybe
how to access MULTIPLE ones!  What if The System (tm) is in CVS, but you
locally mirror it into Subversion or something?  This could snowball
really fast.

> 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).

I think it'd have to be the latter.  The former doesn't give us too much
gain over what we already have (it gives some, of course, since the
merger can know "it's been modified", but if we're gonna bite this
bullet, we might as well bite all the way through at once).

> 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.

And before anybody else says it, what we REALLY want is a versioning
filesystem!  Yeah!  And files like this should have a vendor branch where
the 'upgrades' go!

> 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 

Every time you look at the durn thing, the problem gets bigger   8-}

Matthew Fuller     (MF4839)   |  fullermd@xxxxxxxxxxxxxxx
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/

"The only reason I'm burning my candle at both ends, is because I
      haven't figured out how to light the middle yet"

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]