Please read the HOWTO: Backup first, to know about basic steps using FSVS.
Here another way is presented; and even if you don't want to use FSVS for distributing your files, the ideas presented here might help you keep your machines under control.
Some planning should be done beforehand; while the ideas presented here might suffice for simple versioning, your setup can require a bit of thinking ahead.
This example uses some distinct repositories, to achieve a bit more clarity; of course these can simply be different paths in a single repository (see Using a single repository for an example configuration).
Repository in URL
trunk/ bin/ ls true lib/ libc6.so modules/ sbin/ mkfs usr/ local/ bin/ sbin/ tags/ branches/
Repository in URL
machine1 (similar for machine2):
trunk/ etc/ HOSTNAME adjtime network/ interfaces passwd resolv.conf shadow var/ log/ auth.log messages tags/ branches/
homedirectory in the repository is not needed, and
A/ Andrew/ .bashrc .ssh/ .kde/ Alexander/ .bashrc .ssh/ .kde/ B/ Bertram/
A cronjob could simply loop over the directories in
/home, and call fsvs for each one; giving a target URL name is not necessary if every home-directory is its own working copy.
/in their name, so you might give the URLs names like
home/Andrew- although that should not be needed, if every home directory is a distinct working copy.
Then you install one machine, commit that into the repository as
base/trunk, and make a copy as
The other machines get
base/released as checkout source, and another (overlaid) from eg.
Per-machine changes are always committed into the
machineX/trunk of the per-machine repository; this would be the host name, IP address, and similar things.
On the development machine all changes are stored into
base/trunk; if you're satisfied with your changes, you merge them (see Branching, tagging, merging) into
base/released, whereupon all other machines can update to this latest version.
So by looking at
machine1/trunk you can see the history of the machine-specific changes; and in
base/released you can check out every old version to verify problems and bugs.
machine1is the development machine,
machine2is a client.
machine1$ fsvs urls name:local,P:200,svn+ssh://lserver/per-machine/machine1/trunk machine1$ fsvs urls name:base,P:100,http://bserver/base-install1/trunk # Determine differences, and commit them machine1$ fsvs ci -o commit_to=local /etc/HOSTNAME /etc/network/interfaces /var/log machine1$ fsvs ci -o commit_to=base /
Now you've got a base-install in your repository, and can use that on the other machine:
machine2$ fsvs urls name:local,P:200,svn+ssh://lserver/per-machine/machine2/trunk machine2$ fsvs urls name:base,P:100,http://bserver/base-install1/trunk machine2$ fsvs sync-repos # Now you see differences of this machines' installation against the other: machine2$ fsvs st # You can see what is different: machine2$ fsvs diff /etc/X11/xorg.conf # You can take the base installations files: machine2$ fsvs revert /bin/ls # And put the files specific to this machine into its repository: machine2$ fsvs ci -o commit_to=local /etc/HOSTNAME /etc/network/interfaces /var/log
Now, if this machine has a harddisk failure or needs setup for any other reason, you boot it (eg. via PXE, Knoppix or whatever), and do (3)
# Re-partition and create filesystems (if necessary) machine2-knoppix$ fdisk ... machine2-knoppix$ mkfs ... # Mount everything below /mnt machine2-knoppix$ mount <partition[s]> /mnt/[...] machine2-knoppix$ cd /mnt # Do a checkout below /mnt machine2-knoppix$ fsvs co -o softroot=/mnt <urls>
branches) could be
stable; your production machines would use
stable, your testing environment
testing, and in
unstableyou'd commit all your daily changes.
fsvs tagwould tag all repositories at once? It would have to check for duplicate tag-names (eg. on the
base-branch), and just keep it if it had the same copyfrom-source.
But how would tags be used? Define them as source URL, and checkout? Would be a possible case.
fsvs tag do a merge into the repository, so that a single URL contains all files currently checked out, with copyfrom-pointers to the original locations? Would require using a single repository, as such pointers cannot be across different repositories. If the committed data includes the
$FSVS_CONF/.../Urls file, the original layout would be known, too - although to use it a sync-repos would be necessary.
Depending on the number of machines it might make sense to put them in a 1- or 2 level deep hierarchy; named by the first character, like
machines/ A/ Axel/ Andreas/ B/ Berta/ G/ Gandalf/
# For the base-system: trunk/ bin/ usr/ sbin/ tags/ tag-1/ branches/ branch-1/ # For the machines: machines/ machine1/ etc/ passwd HOSTNAME machine2/ etc/ passwd HOSTNAME
base/ trunk/ bin/ sbin/ usr/ tags/ tag-1/ branches/ branch-1/ machine1/ trunk/ etc/ passwd HOSTNAME tags/ tag-1/ branches/ machine2/ trunk/ etc/ passwd HOSTNAME tags/ branches/
trunk/ base/ bin/ sbin/ usr/ machine2/ etc/ passwd HOSTNAME machine1/ etc/ passwd HOSTNAME tags/ tag-1/ branches/ branch-1/
So keep your base installation at highest priority, and you've got good chances that you won't loose control in case of conflicting files.
Until then you'd need a custom boot CD, or copy the absolute minimum of files to the harddisk before recovery.
There's a utility
svntar available; it allows you to take a snapshot of a subversion repository directly into a
.tar -file, which you can easily export to destination machine. (Yes, it knows about the meta-data properties FSVS uses, and stores them into the archive.)
baserepository are changed only on a single machine, and so there's an unidirectional flow.
BTW, how would you merge your binaries, eg.
users [at] fsvs.tigris.org.