Login | Register
My pages Projects Community openCollabNet

Purpose of FSVS

Overview

FSVS should do two things:
  • Make reliable, compressed, non-intrusive, versioned backups with meta-data support.
  • Help in system deployment.

Backups

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 exist; but they don't have much chance to be ever included, in spite of issue 1256 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).

System deployment

Example tree:
base/
   trunk/
   tags/
     version-1/
     version-2/
     version-3/
   released/
user/
   anthony/
   bertram/
   charlie/
machine/
   workstation-1/
   workstation-2/
   workstation-3/
software/
   package-1/
   package-2/
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 eg. machine/A.
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.