Date: Fri, 25 May 2007 13:43:42 +0300 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: Brian Candler <B.Candler@pobox.com> Cc: freebsd-current@freebsd.org Subject: Re: Using Subversion for binary distribution? Message-ID: <20070525104342.GA2761@kobe.laptop> In-Reply-To: <20070525074925.GA19294@uk.tiscali.com> References: <20070525074925.GA19294@uk.tiscali.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2007-05-25 08:49, Brian Candler <B.Candler@pobox.com> wrote: > Here's a wacky idea - I don't know if anyone's considered it before. Not so wacky. Ok, maybe a little wacky... see below :) > Suppose you checked a full *binary* FreeBSD distribution into Subversion > (that is, untar all the distribution bundles and then svn import) > > Now, on a target machine, you do "svn checkout .... /mnt" where /mnt has > mounted a blank disk. Then install the boot loader, and then boot from that > disk. > > What you get is the following: > > * Binary updates. If you check in binary updates to the repository, then > "svn update" on all the clients will perform the update. > > * "svn status" shows you what files you have changed or added on the machine > (without generating any network traffic). Note: this can be done in any > subdirectory, e.g. /etc, not just at the root. > > * Piping "svn status" into a backup script would backup only the minimum set > of files and directories needed to recreate the machine. > > * "svn diff" would show what config changes you had made on a system, and > "svn revert" would wind them back to how they were at the original > installation (again, without generating any network traffic) > > * Upgrading to a new release would just be a case of "svn switch ...; > svn update" > > * Upgrading would correctly delete files which were present in the old > release, not present in the new release, and not modified by you. Yay! Clean > systems even after multiple upgrade cycles!! > > * Provides a replacement for "mergemaster": "svn update" will automatically > merge in non-conflicting changes to all your config files, and highlight > where there are conflicts for you to fix manually. > > For the more advanced user, you could create a separate branch in your > central repository for each endpoint machine, allowing you to drive config > changes from the repository. (The downside is that when you upgrade to a new > release you'll need to merge these branch changes into the new branch) > > Is there any value in pursuing this idea? Yes, there probably is at least some amount of value in this. What you are describing is, essentially, a way of creating a single, huge "binary package" of the FreeBSD base system. Using Subversion of a more distributed system like Git and Mercurial, can work in the way you are describing, but you would have to be _very_ careful about file ownership (so that you don't accidentally leak files owned by root to other accounts, for example), and permissions (so that you don't suddenly let everyone read /etc/master.passwd, or something equally or more evil). Subversion support for making 'local' changes to a checked out workspace and keeping them local is simply unavailable. The checked out tree would be "polluted" with .svn/ subdirectories with all the metadata of the Subversion workspace too (that's where permissions will be tricky to get right). The disk space requirements of a Subversion checkout are also very big. At least twice the size of the checked out files, and then some more. PS: Have you already tried systems like sysutils/cfengine and given up on them for your own reasons?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070525104342.GA2761>