Purpose of FSVS
FSVS should do two things:
- Make reliable, compressed, non-intrusive, versioned backups with meta-data support.
- Help in system deployment.
As long as you regularly commit your machine's files, you're safe.
If your harddisk dies, you just update to the last version;
if you destroy or remove a file per accident, you can choose a version
from your repository.
Most of that can be done by subversion
today; what FSVS does more:
- meta-data support (although patches for subversion
but they don't have much chance to be ever included, in spite of
and many wishes on the mailings lists);
- non-intrusive means that there are no .svn subdirectories in every directory.
(This is like svk, but that's IMO slow and needs a local repository).
The advantage over using rsync
is the availiability of many versions per file,
and storing these compressed; scripts exist to have a few versions backuped with rsync,
but they're all full-text. (At least the changed files use their full size).
Imagine having 10 similar machines with the same base-installation.
Then you install one machine, check that into the repository as base/trunk
and make a copy as base/released
The other machines get base/released as checkout source, and another (overlayed) from
Per-machine changes are always committed into the machine/*-parts of the repository; this
would be eg. hostname, 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 into base/released, whereupon all other machines can update
to this latest version.
So by looking at machine/X you can always see what makes this machine different
from the others; and in base/released you can check out every old version to verify
problems and bugs.
It would be reasonable to have another tree in the repository for the user-data, eg user/X.
On user installation this directory would be checked out onto the machine below /home, and the user has the same data
area everywhere, and backuped as often as the administrator tells cron to do commits.
Optional software packages could be stored in another subtree. They should be of lower priority than the
base tree, because if conflicts arise1,
the base should always be prefered, to make sure that the machine
is at least accessible (it's better that a software doesn't work than that the machine stops working).
Note 1: Conflicts should not be "auto-merged". If two or more trees bring the same file,
the file from the "highest" tree wins.