From owner-freebsd-current@FreeBSD.ORG Fri May 25 11:52:47 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 8329516A502 for ; Fri, 25 May 2007 11:52:47 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune.pobox.com (rune.pobox.com [208.210.124.79]) by mx1.freebsd.org (Postfix) with ESMTP id 4761013C45D for ; Fri, 25 May 2007 11:52:47 +0000 (UTC) (envelope-from b.candler@pobox.com) Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 89FA5F06A8; Fri, 25 May 2007 07:53:08 -0400 (EDT) Received: from localhost (80-45-95-114.static.dsl.as9105.com [80.45.95.114]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id C36A4F06A5; Fri, 25 May 2007 07:53:06 -0400 (EDT) Received: from brian by localhost with local (Exim 4.60) (envelope-from ) id 1HrYLb-0008SL-0q; Fri, 25 May 2007 12:52:43 +0100 Date: Fri, 25 May 2007 12:52:42 +0100 From: Brian Candler To: Giorgos Keramidas Message-ID: <20070525115242.GA31555@uk.tiscali.com> References: <20070525074925.GA19294@uk.tiscali.com> <20070525104342.GA2761@kobe.laptop> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070525104342.GA2761@kobe.laptop> User-Agent: Mutt/1.5.11 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 11:52:47 -0000 On Fri, May 25, 2007 at 01:43:42PM +0300, Giorgos Keramidas wrote: > 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). That's a very good point. There's svn:executable, but that's only a small part of the equation. Perhaps mtree-like settings could be put into a user property, and a post-checkout script could enforce them. The problem is, I believe, analagous to what happens when you do the initial system build and create the tarballs: you have to ensure that all the files in the tarballs are owned by the correct accounts and have the correct mode (not root:root and 0755, or whatever they got when the compiler built them) If you put this information in an appropriate place for the client, it can apply it locally after it has done an svn checkout. > 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. Having .svn directories all over the place is not a worry to me, and in fact that's what gives you most of the practical advantages: svn diff and svn revert will depend on this, as well as merging of non-conflicting changes. rm /bin/ls svn revert /bin/ls # happy days :-) Permissions on the .svn directories need to be gotten right, but I think that simply setting them to root:root 0700 would be safe. You'd have a hard job finding a disk below 160GB these days, so the size utilisation doesn't bother me either. Similarly, it gets a bit more complicated if you try to keep the distribution sets separate, so I'd be inclined to install all distributions regardless. You could set svn:ignore on /usr/games if you wanted. > PS: Have you already tried systems like sysutils/cfengine and given up > on them for your own reasons? Actually, it's the FreeBSD "upgrade" process which I've given up on. Doing a binary upgrade leaves loads of crud around on your hard drive, and doesn't handle config files properly (i.e. no "mergemaster" support). Doing source upgrades, well, requires lots of compiling, and a lot more disk space again. For this reason, I've migrated most of the machines I use to Linux - sorry :-) My laptop remains on FreeBSD (5.4), but maybe even that'll have to go soon. Regards, Brian.