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."

Oh I like that

[The Munger]

That's a smart way of doing things. I've found version control to be worthwhile on even single user projects. Having the same kind of backup/restore and history tracking on every one of your files just makes sense. I'm suprised no-one has done this sooner.

In a slightly more abstract sense, it provides a 'working set' of documents on your computer. Comments on your version history adds meta-data to files that is time-based. Most systems at the moment add meta-data that is for the current file. Imagine, you check in some files with a comment like 'Project: holiday snaps 03'. Then later on, you use one of those files in a presentation 'Project: report for Bill 03'. With standardised formatting of such tags, the file keeps with it the idea that it has been used with multiple projects at different times. That's a powerful method of grouping.

Ever been in the situation where a file belongs with multiple projects? With your standard directory structures, you might put it in one directory and shortcut/alias/whatever it in the other (or maybe make a second copy). It's pretty ugly right? What if you could say, this file belongs to both of these projects, and you could even provide the old version that was used in another project. OK, so all of that would require some more automation - we can dream can't we?

That has a lot of possibilities.

ssh private keys

[smcavoy]

somehow I don't like the idea of my private ssh keys being sown like a seed across a number of systems.
To much of a headace worrying about where they are, were they deleted properly... etc.

Re:Why just home?

[pclminion]

The basic problem with versioning in the file system is deciding when to commit. Do you commit for every byte written? Of course not, that would be a massive waste of time and disk space. Do you commit once for every write() call? That suffers the same problem, because sometimes writes are very small, and you can never predict in advance how large a write will be.

You can't automatically commit after every xxx bytes of data written, because that means there will be a bunch of intermediate states on disk, most of which are probably bogus (this argument applies to the above two options as well).

The only thing that even remotely makes sense is to commit on close(), but that doesn't make sense for applications like text editors which keep the file open for the entire duration. You want each SAVE to be a commit, not each CLOSE.

What this boils down to is that there must be application level support for the commit operation (i.e., a new commit() syscall). The application has to specifically be coded to tell the operating system "Ok, I'm done with the revision, commit this now." And that means every application on the system will have to be tweaked to make the necessary commit calls, not to mention the thought that goes into deciding WHEN it is appropriate to commit. I would wager that a lot of maintainers wouldn't bother to make those changes, and as a result those applications wouldn't support versioning.

I agree that a versioned file system would kick ass, and there are even some out there already (Google for "versioning filesystems"). But they tend to be special purpose. I don't see how it could be cleanly and transparently integrated into a general purpose system such as Linux.

Note that I didn't bother to check CiteSeer to see if there is academic work on this before posting this comment. So if anyone knows of any work toward that end, I'm sure a lot of us would appreciate a pointer to it.

Re:Why just home?

[cpghost]

This is the reason database transactions exist. A filesystem based on CVS would need the concept of (atomic) transactions: you open(2) the file, therefore starting a transaction. Every access (read(2)) and modification (write(2)) etc... goes in the transaction _only_, and at close(2), the transaction gets commited.

The funny part starts at close() (or commit())-time, when you need to resolve conflicts. Huh...

Renaming a directory

[Henry Stern]

I shudder to think what happens when he tries to rename his files and directories.

Definitely the biggest problem with CVS. :(

Re:Described in Linux Journal months ago

[hondo77]

There's nothing about "new" mentioned anywhere in there, you pulled that out of your ass just so you could complain.

Merriam-Webster defines news [m-w.com] as "a report of recent events". If Slashdot is "News for Nerds" then an article from over a year ago ain't news.

Re:Why just home?

[Anonymous Coward]

I'll get modded down to oblivion for mentioning an MS product in a positive light, but Windows XP+2003 Server supports this already.

So does Windows XP Pro. It's called "System Restore". I don't think that it works for every single file, but it does a lot of that stuff, keeping old config files around and so on.

And no, you won't get modded down for mentioning an MS product in a positive light as long as your mention _makes sense_ (and doesn't incorrectly trash Linux in the same breath). However, the second they come up with a (-1, Irritating Marytr Complex) mod, you're dead. :)

Rsync anyone?

[pico303]

Isn't this what rsync is for? CVS seems to be the wrong tool for this job.

Re:Described in Linux Journal months ago

[zsau]

Perhaps it's stuff that matters?