From owner-freebsd-current@FreeBSD.ORG Fri May 25 10:45:37 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF10D16A41F for ; Fri, 25 May 2007 10:45:36 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from igloo.linux.gr (igloo.linux.gr [62.1.205.36]) by mx1.freebsd.org (Postfix) with ESMTP id 70E4913C465 for ; Fri, 25 May 2007 10:45:36 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from kobe.laptop (host5.bedc.ondsl.gr [62.103.39.229]) (authenticated bits=128) by igloo.linux.gr (8.13.8/8.13.8/Debian-3) with ESMTP id l4PAi01u005819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 25 May 2007 13:44:06 +0300 Received: from kobe.laptop (kobe.laptop [127.0.0.1]) by kobe.laptop (8.14.1/8.14.1) with ESMTP id l4PAhgUK054825; Fri, 25 May 2007 13:43:54 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by kobe.laptop (8.14.1/8.14.1/Submit) id l4PAhg9S054824; Fri, 25 May 2007 13:43:42 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Fri, 25 May 2007 13:43:42 +0300 From: Giorgos Keramidas To: Brian Candler Message-ID: <20070525104342.GA2761@kobe.laptop> References: <20070525074925.GA19294@uk.tiscali.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070525074925.GA19294@uk.tiscali.com> X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-3.525, required 5, autolearn=not spam, ALL_TRUSTED -1.80, AWL 0.67, BAYES_00 -2.60, DNS_FROM_RFC_ABUSE 0.20) X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Spam-Status: No Cc: freebsd-current@freebsd.org Subject: Re: Using Subversion for binary distribution? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2007 10:45:37 -0000 On 2007-05-25 08:49, Brian Candler 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?