Home Directory In CVS

shamir_k writes "Joey Hess has come up with an innovative solution to a problem we have all faced. He's put his whole home directory in CVS. Not only can he move between multiple computers easily, he also has automatic distributed backups."

Comments

Described in Linux Journal months ago

[HuguesT]

This is innovative but not new, the LJ article is dated September 2002.

Waky, waky editors?

My favorite directory to put in CVS

[Beryllium Sphere(tm)]

/etc

Have a checkin comment for why a configuration change got made. Be able to roll back a failed experiment reliably. Find out when a change happened.

I wonder.....

[The One KEA]

Has anyone tried this with BitKeeper?

Why just home?

[AuMatar]

I asked this on a local linux mailing group recently- what do people think about the idea of a version control file system? Disk space is cheap these days, we can afford it space wise. Think of all the problems it would solve.

*Made a mistake in your config file? Revert it
*User deleted the file? Revert it
*Want to see why you made a change to any given file? Check the comments (commenting would be optional, of course)
*Your system was exploited? Revert the entire system to before the exploit
*Upgraded an app and regret it? Revert the files

And so on. I'm not sure if CVS would be the best method (I'm not a SCM specialist), but I'd see this as an extremely useful feature who's time has come.

Re:Why just home?

[bcrowell]

The basic problem with versioning in the file system is deciding when to commit.
I use Unison for this, and it works great. A commit happens whenever I choose to run Unison. I'm a human. Unlike a computer, I understand what I'm doing and why. I know when I'm done working on something, and when I'm ready to synchronize my files.

From the article:

• I get three major benefits from keeping my whole home directory in CVS: home directory replication, history and distributed backups.

I get all these benefits from Unison. Admittedly, the history only gives me snapshots at two different times (time 1=now, time 2=last time I committed), but that's always been good enough for me. Deleted the wrong file? No problem -- get it back from the other machine.

Unison is also cool because, unlike CVS, it (a) is easy to set up and maintain, (b) is quick and easy to run, and (c) works just as easily with binary files as with text files.

Or just RCS

[A nonymous Coward]

I put RCS subdirs all over, check files in and out.

It also makes complete OS upgrades easier, I use the RCS subdirs to tell what I changed from the base install.

How does he handle renaming and erasing in CVS?

[Anonymous Coward]

'cause CVS loses the history in these operations.

Re:How does he handle renaming and erasing in CVS?

[neonleonb]

Alias mv to execute some shell script:
mv $1 $2
cvs remove $1
cvs add $2
cvs commit -m "move $1 $2" $1 $2
You might want to add some script to deal with the case where $2 is a directory, but that shouldn't be too hard.

That way, information about the move and the previous file status is kept.

auto-backups the plan9 way

[DrSkwid]

Plan9 has the mantra : "file creation is forever"

Automated incremental backups are a way of life.

With Venti one can even back up two windows/linux machines and *not* use up disk space for commonly used blocks, so backing up 100 machines wont use up the usual 1Gb each for the duplicate libs/windows directories.

The yesterday command give you the power to browse back through your life

Find what has changed in the C library since March 1:

yesterday -d -0301 /sys/src/libc/port/*.c

When did you say this guy did the innovation again?

Subversion rocks!

[Anonymous Coward]

Obligatory link to Subversion, since this new-fangled hypertext media allows it.

(With a hint of sarcasm for you mentioning it but not linking!)

From personal experience it seems to be quite usable already. Although I did find it hard to install and get everything set up properly (path problems, etc) partly because I'm a Visual SourceSafe refugee. I'm still not quite used to the pathing schemes and checkin model and am still confused by wanting to assign a VSS-style 'working directory' to a Subversion folder and not knowing what to do about that.

Great for Mozilla settings!

[adamfranco]

I currently store parts of my .thunderbird and .phoenix directories in CVS and do the commit/update to sync work and home. In general it works pretty well, though not all my settings translate well between OS X (work) and Red Hat (home). For this reason in particular, extensions are not in my CVS and this makes keeping stuff custumized a bit of a pain still.

unison is probably a better solution

[penguin7of9]

My recommendation: use the Unison file synchronizer to keep multiple copies of your home directory in sync.

It's not quite the same thing as CVS, but that's probably a good thing. Most importantly, it won't give you versioning. On the other hand, it is symmetric (meaning, none of the copies are distinguished) and it is much less hassle to use. Also, you can define custom merge methods to automate merging of things like mailboxes. Unison is great for keeping a home directory (or portions of it) in sync between different desktops, and between desktops and laptops.

Note that for live backups, rsync is probably still the best choice because you want something unidirectional.

Re:unison is probably a better solution

[penguin7of9]

Rsync can actually be used in that fashion too, BTW, right out of the box, and it works well too.

No, it cannot. rsync is a uni-directional file synchronizer and it doesn't have an interactive interface. unison is a bi-directional file synchronizer with non-timestamp-based change detection and a GUI for resolving conflicts. The two are completely different things. unison does much more than rsync.

However, versioning allows you to go back to the most useful prior version of the file, not just the most recent. What if you finally managed to get your configuration right last week, but that version got overwritten by the version with "just one more tweak" that was used for this week's rsync/unison run?

Unison can create histories and backups if you like, even on a path or type-dependent basis. In several years of using it, I have never bothered because all the applications I use already keep their own backups or histories. (Incidentally, rsync can keep version histories and backups, too.)

I guess I should mention, just for the sake of full disclosure (not because it's really relevant) that I'm a product architect at a company seeking to do provide just this sort of "go back to any time" functionality at the block level. Of course I have some strong opinions about the relative utility of "single point in time" vs. continuous backup/restoration, or I wouldn't have taken the job.

Such systems have been around since at least the 1980's. Most people who have used them (including myself) have found them to be profoundly useless even though they worked exactly as advertised and were really easy to use.

Over several decades of experience with such systems, people generally have come to the conclusion that versioning and histories are application-dependent and best left to applications. That's why systems like Emacs, Microsoft Word, etc. have that sort of thing built in and why people use CVS on a per-project basis.

(And, in the interest of full disclosure, I have no commercial interest whatsoever in any of these systems.)

Been doing that a *long* time

[Anonymous Coward]

I've been keeping my home directory in CVS since 1996. Prior to that, I kept it in RCS, since around 1985, and briefly in SCCS.

I haven't yet decided to go to Subversion, in part because I have a patched version of CVS that allows me to check into multiple CVS repositories - i.e. I can check in when on my laptop on an airplane, disconnected from the net, and can later check in to my main repository when I get connected. (Yeah, yeah, BitKeeper is a way to do that.)

As Joey's article discusses, there are minor issues with CVS'ing your home directory: use of modules, etc. I divide it into stuff that is owned by the company that I am currently working for, and stuff that I own.

When I get an account on a new machine, one of the first things that I do is create a new branch (or, a new version on some existing branch) to hold the dot files and other files
that were pre-installed in my home directory. Having saved them, I then blithely overwrite them with my standard home directory, and maybe do a quick check to see if there are any special features worth propagating to my standard home directory.

Oh, yeah: a bit of footwork to checkout
onto your home directory:

cd ~
mv * .* /tmp/glew/old-home-directory // actually, usually saved already
cvs -d MYSERVER co glew-home
mv glew-home/{*,.*} .
rmdir glew-home

I often find myself pasting together
modules from different repositories.
Sometimes I *want* a "cvs update"
in the root, e.g. in ~, to traverse
repository boundaries - no problem.
But sometimes I don't - e.g. I frequently
work in ~/hack, and check out stuff into there.

To do this, I have fallen into the habit
of creating a CVSBARRIER directory that is
not checked in, that prevents cvs update
from traversing.

Also, I find it useful to have a place
to put overall comments for a repository.
Typically, this is ~/README or ~/CVS-status.
The overall comments - such as "the tag
named FOO is my home directory at the time
I moved to university BAR and merged in
changes from my laptop BAZZ that had diverged"
get suck in the CVS log, via
cvs ci -f CVS-status.

Oner thing: when yiou have as much history as this, you notice when programs change their interface. E.g. nmh doesn't run my ~/.mhrc from 1994 :-(

--- Andy "Krazy" Glew
(I'm too lazy to create a slashdot account)

rcsvi for easy sysadmining

[negyvenot]

rcsvi is a simple wrapper for vi that puts edited files under revision control. It does not support any vi flags. It only takes one file argument and an optional revision number for reverting to previous versions. A few examples:

# alias vi=rcsvi
# vi /etc/passwd
[ remove Agent Smith's account ]
:wq
/etc/passwd: 12 lines, 94 characters.
enter log message, terminated with single '.' or end of file:
>> Agent Smith's account removed.
.

Voila. You now have your passwd file under revision control. More examples:

# vi -r1.2 /etc/passwd
# rlog /etc/passwd
# rcsdiff -r1.2 -r1.3 /etc/passwd

To make a complete backup of your system configuration:

# tar fc /tmp/RCS.tar $(find / -type d -name RCS)

Now you may ask "ok i want to edit multiple files and/or do some other trickery". Don't. It's a simple tool, that i'm using for years now with great satisfaction.

Check it out here

CVS for /etc

[SCY.tSCc.]

CVS serves great for our /etc directory. There are 9 administrators that may fiddle around with the configuration and CVS is used to keep track of the who-changed-what-and-why thing.

All it takes is a bit of discipline to check in your changes in case you're not used to it. A daily cvs -nq up -dPR helps to find the files you forgot to check in.

Re:Not Innovative

[Inflatable Hippo]

> What's next? Keeping system configuration in CVS?

Hey! I claim "prior art"!

Seriously, I do this for entire binary installations including all configuration files for a custom server we've written.

It's a really nice solution.

One of the really great benefits is when someone has been footling some of the more complex configuration and broken things. It's really easy to find which files they've changed and what the changes are.

Sure there's nothing you couldn't any other way but it it certainly makes lots of things easier.

No doubt you could go further than we have with all sorts of fancy cron jobs to auto-update from a "trusted" branch nightly across your 5000 production servers but we only have 2 :-)