[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Need to version control entire root file system

From: Thomas Harold <tgh_at_tgharold.com>
Date: 2007-06-22 21:28:23 CEST

Worley, Chris B wrote:
> Not user's home directories, but everything else; and no version control
> meta-data cruft left lying around inside my image.

FSVS does not create .svn sub-folders. It does use a /var/spool/fsvs
folder to cache information and also creates a few files under /etc/fsvs
(as of the v1.1.5 release).

The back-end storage is a regular ol' SVN repository, so you can use all
of the SVN tools on the repository. For instance, the GUI configuration
tool for Apache in CentOS5 trashed my httpd.conf file. I fired up
TortoiseSVN on my WinXP laptop, browsed the repository and took a look
at the differences between the versions. I could've even fixed it on
the laptop, then used SVN to transfer the changes back to the server.

> Ascii files need explicit diffs, binary files can just be flagged as
> changed. I need to be able to view which files changed at any check-in
> point, what files are different now from the last check-in, how the
> ASCII files changed between any two versions, and roll-back the entire
> image to any previous version.

I'm not exactly sure how good FSVS is at rolling back an entire file
system. There are some thorny issues there - especially if you toss
SELinux (which puts extended attributes into the file system) into the
mix. I haven't tried to use it as a "system restore point" or in
snapshot mode.

(Personally, I'm leaning towards using FSVS only for /etc and a few
other selective folders - then using another tool to take periodic
snapshots of the system that can be restored. Tools like Amanda or
rdiff-backup. Down the road, ZFS looks promising because it combines
LVM, RAID and the file system into a single unit which allows you more
flexibility to do things seamlessly.)

IOW, I'm thinking that FSVS is extremely well suited for undoing minor
"oops" and for tracking file changes. But I'm not sure of its
suitability for disaster recovery and bare metal restore (situations
where a tool like Bacula / Amanda may be better).

> Mostly, I need the diff repository to be outside the image; I don't want
> hidden version control directories in every directory of my file
> system... I need the version control meta-data kept elsewhere (this
> image gets provisioned onto systems).

FSVS has an interesting concept here. You can lay multiple repository
URLs over top of the system, so that when you do a "fsvs update", the
highest priority URL takes effect. Not something that I have experience
with yet or fully understand. The idea is that you have a "base" image
with smaller overlays for individual machines.

(I've used both SVN and FSVS to manage /etc. FSVS is definitely the
cleaner solution. That it works with regular SVN tools and stores its
information in a regular SVN repository makes it useful for different
purposes then rdiff-backup or rsnapshot.)

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 22 21:29:02 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.