Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 May 2007 08:49:26 +0100
From:      Brian Candler <B.Candler@pobox.com>
To:        freebsd-current@freebsd.org
Subject:   Using Subversion for binary distribution?
Message-ID:  <20070525074925.GA19294@uk.tiscali.com>
Resent-Message-ID: <20070525094727.GA26257@uk.tiscali.com>

next in thread | raw e-mail | index | archive | help
Here's a wacky idea - I don't know if anyone's considered it before.

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?

Cheers,

Brian.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070525074925.GA19294>