Date: Tue, 20 Apr 2010 11:30:06 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Jeremie Le Hen <jeremie@le-hen.org> Cc: hackers@freebsd.org Subject: Re: /etc in CVS (was: Another tool for updating /etc) Message-ID: <20100420183007.481F85B4D@mail.bitblocks.com> In-Reply-To: Your message of "Tue, 20 Apr 2010 00:14:13 %2B0200." <20100419221413.GD76198@felucia.tataz.chchile.org> References: <201003231108.45102.jhb@freebsd.org> <20100324165748.7334B5B42@mail.bitblocks.com> <20100419221413.GD76198@felucia.tataz.chchile.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 20 Apr 2010 00:14:13 +0200 Jeremie Le Hen <jeremie@le-hen.org> wrote: > Hi Bakul, > > Sorry for the late reply, I'm lagging behind in my FreeBSD mailbox :). > > On Wed, Mar 24, 2010 at 09:57:48AM -0700, Bakul Shah wrote: > > > > But I wonder... why not build something like this around cvs? > > Basically a three way merge is exactly what we want for /etc, > > right? cvs because it is in the base system. I used to > > maintain /etc changes in cvs and that was useful in keeping > > track of configuration changes on shared machines. > > By the way, I've been storing my configuration in CVS for a long time > and I have created a full-fledged tool to help this. Given you're using > cvs(1) to store your changes in /etc, you may find it useful. The main > purpose of the script if to verify that everything is checked in and you > didn't overlook to commit a change. This can very easily be run from > a crontab(5). ... > http://jlh.chchile.org/cvsconfchk/ Thanks.... I will check it out. My suggestion was in the context of upgrding a system to a new release. There are changes to /**/etc/**/*(.) files going from release R to R+1. I was pointing out that what mergemaster does (merging in these changes to your locally modified etc files) is almost exactly the same as merging in a vendor branch under CVS (vendor here would be freebsd.org). But merge conflicts have to be resolved carefully and before any reboots! I understand John Baldwin's response as to why not cvs but I haven't thought more about this until today. It may be possible to create a separate tool around SCM of one's choice.... Anyway, I'll shut up about this unless I can come up with such a tool. But don't hold your breath. Conversely, mergemaster-like interactive scheme can be handy for managing cvs vendor branch merge conflicts (or three way merges in git or hg). Here's an idea... May be just that logic can be factored out in a separate script that can be run *after* a merge or update. The problem really worth solving is an atomic rollback in case an upgrade fails. This is either trivial (if you use zfs) or very hard! But instinctively I shy away from relying on a complicated FS like zfs for something as basic as this. [/**/etc/**/*(.) is a zsh expression to specify every file in every "etc" dir in a system.]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100420183007.481F85B4D>