Date: Fri, 25 May 2007 12:52:42 +0100 From: Brian Candler <B.Candler@pobox.com> To: Giorgos Keramidas <keramida@ceid.upatras.gr> Cc: freebsd-current@freebsd.org Subject: Re: Using Subversion for binary distribution? Message-ID: <20070525115242.GA31555@uk.tiscali.com> In-Reply-To: <20070525104342.GA2761@kobe.laptop> References: <20070525074925.GA19294@uk.tiscali.com> <20070525104342.GA2761@kobe.laptop>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070525115242.GA31555>