Re: Using Subversion for binary distribution?

On 2007-05-25 08:49, Brian Candler <B.Candler_at_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?