Re: /etc in CVS
On Thu, Apr 22, 2010 at 04:41:27PM +0200 I heard the voice of Ulrich Spörlein, and lo! it spake thus: I have a .hg directory sitting in / for every machine I usually take care of. hgignore is of course set to *, so only explicitly added files are tracked. I do pretty much the same thing (except mine has .bzr/ and .bzrignore ;). Using the VCS to handle updates requires something a bit broader though. I HAVE considered it. You'd need to do the sort of 'make install' stuff mergemaster does to a tempdir, and make a branch there checking in the snapshots, and have your etc be a derived branch from that. That way you have all the VCS merge capabilities to do the merges and track where they came from. Mergemaster works well enough that I've given no serious thought beyond idle that would be cool thinking on the matter though 8-} -- Matthew Fuller (MF4839) | fulle...@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS
On Friday 23 April 2010 2:50:15 am Matthew D. Fuller wrote: On Thu, Apr 22, 2010 at 04:41:27PM +0200 I heard the voice of Ulrich Spörlein, and lo! it spake thus: I have a .hg directory sitting in / for every machine I usually take care of. hgignore is of course set to *, so only explicitly added files are tracked. I do pretty much the same thing (except mine has .bzr/ and .bzrignore ;). Using the VCS to handle updates requires something a bit broader though. I HAVE considered it. You'd need to do the sort of 'make install' stuff mergemaster does to a tempdir, and make a branch there checking in the snapshots, and have your etc be a derived branch from that. That way you have all the VCS merge capabilities to do the merges and track where they came from. Mergemaster works well enough that I've given no serious thought beyond idle that would be cool thinking on the matter though 8-} etcupdate essentially seeks to do a simplified version of the vendor imports by just keeping the last two imports around so that each new import can be applied. This does mean it is more limited than a full source code control solution, but it also ends up being more lightweight. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS
Sergey Babkin bab...@verizon.net writes: I wonder if a version control system, like SVN, could be used to keep track of all the changes in /etc. (Or maybe it already is and I'm simply out of date). arch is commonly used for things like this. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS
On Thu, 22.04.2010 at 12:18:21 +0200, Dag-Erling Smørgrav wrote: Sergey Babkin bab...@verizon.net writes: I wonder if a version control system, like SVN, could be used to keep track of all the changes in /etc. (Or maybe it already is and I'm simply out of date). arch is commonly used for things like this. I have a .hg directory sitting in / for every machine I usually take care of. hgignore is of course set to *, so only explicitly added files are tracked. FWIW, I would *strongly* suggest you do *not* use SVN, but a system capable of offline usage, because when the shit hits the fan, you can't rely on a working network. just my two cents, Uli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS
On Thu, 22.04.2010 at 12:10:50 -0400, Mike Meyer wrote: On Thu, 22 Apr 2010 16:41:27 +0200 Ulrich Spörlein u...@spoerlein.net wrote: On Thu, 22.04.2010 at 12:18:21 +0200, Dag-Erling Smørgrav wrote: Sergey Babkin bab...@verizon.net writes: I wonder if a version control system, like SVN, could be used to keep track of all the changes in /etc. (Or maybe it already is and I'm simply out of date). arch is commonly used for things like this. I have a .hg directory sitting in / for every machine I usually take care of. hgignore is of course set to *, so only explicitly added files are tracked. FWIW, I would *strongly* suggest you do *not* use SVN, but a system capable of offline usage, because when the shit hits the fan, you can't rely on a working network. My take is the exact opposite: when the shit *really* hits the fan, you can't rely on data from the local disk, so you want your VCS data to be stored somewhere else. Ideally, the VCS has *everything* on the remote server, including data about what's checked out where, so your worst case is to reinstall the base OS and then just checkout everything. I take it you have never worked with a distributed SCM then. As there are checksums that can assure integrity and, more importantly, distributed SCMs can of course get data over the network from a central storage. Also, ZFS and geli provide further data integrity mechanisms for the truly paranoid. Regards, Uli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS
Doug Barton wrote: On 4/20/2010 11:30 AM, Bakul Shah wrote: 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! That's not accurate. By default mergemaster does nothing, it will not change your installed /etc at all. At this point the -U option will handle major release upgrades quite painlessly, leaving only those files that actually have local mods for the user to deal with manually. Of course, I have always said that if anyone feels compelled to create a better solution for etc merging that they should feel free, and I still mean that. :) I wonder if a version control system, like SVN, could be used to keep track of all the changes in /etc. (Or maybe it already is and I'm simply out of date). -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS (was: Another tool for updating /etc)
On Tue, 20 Apr 2010 00:14:13 +0200 Jeremie Le Hen jere...@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.] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS
On 4/20/2010 11:30 AM, Bakul Shah wrote: 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! That's not accurate. By default mergemaster does nothing, it will not change your installed /etc at all. At this point the -U option will handle major release upgrades quite painlessly, leaving only those files that actually have local mods for the user to deal with manually. Of course, I have always said that if anyone feels compelled to create a better solution for etc merging that they should feel free, and I still mean that. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /etc in CVS (was: Another tool for updating /etc)
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). The name of this tool is very lame, I didn't find a better one for now. If you have a proposition, I'm all opened to it! You will find a link to download the tool and the whole manpage at the following URL. An example session at the end of the manpage that show you how to use the tool interactively: http://jlh.chchile.org/cvsconfchk/ If you give it a try, do not refrain from giving me some feedback! Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
