Another point I note is that working-copy filesystem integration seems to be a weak point of all version control systems. Particularly when it comes to file/directory renames, adds, and deletes.

Actually, I think the post you reference is talking about a different problem -- designing merging algorithms that Don't Do Bad Things. It's working on the basis that you already have different branches containing existing commits, and want to sensibly merge the changes.

Ah, but the problems often revolve around renames and/or deletes, which are also the weak points in working copy integration.

And this is one of the places where content-addressable-based systems like git really shine -- you don't have to explicitly specify these actions at all! Because it's taking a snapshot of the entire working set, you it's not necessary to explicitly tell it that you renamed file A to file B just so that it can maintain a complete history for particular chunks of code; instead, git (for example) calculates this information on-the-fly at history-inspection time.

How's it detect a file being renamed and modified, though? Without being explicitly told it's happened, there's then only heuristic connections between that operation and a simultaneous deletion of a file and a creation of a new one.

Not only does this save an administrative burden, it can track content at the content rather than at the file level -- and is thus able to faithfully show content history in circumstances that simpler tools like SVN simply can't represent properly, such as a single file being split up into many smaller ones.

I was wondering about ways of merging changes within a file (eg, reordering lines) and changes between files (eg, renames) in the same way; store the entire repository as something like a giant tar file using a diff algorithm that detects moved regions...

Actually, I think the post you reference is talking about a different problem -- designing merging algorithms that Don't Do Bad Things. It's working on the basis that you already have different branches containing existing commits, and want to sensibly merge the changes.

What you're talking about is having (in SVN, for example) to explicitly tell the version-control system about file renames, deletions, and other changes that you've made in preparation for adding a brand-new commit to history.

And this is one of the places where content-addressable-based systems like git really shine -- you don't have to explicitly specify these actions at all! Because it's taking a snapshot of the entire working set, you it's not necessary to explicitly tell it that you renamed file A to file B just so that it can maintain a complete history for particular chunks of code; instead, git (for example) calculates this information on-the-fly at history-inspection time.

Not only does this save an administrative burden, it can track content at the content rather than at the file level -- and is thus able to faithfully show content history in circumstances that simpler tools like SVN simply can't represent properly, such as a single file being split up into many smaller ones.

I just noticed a parallel between the VCS issue of ignoring generated and temporary files (.cvsignore, svn:ignore, and so on) and my thoughts on separating different types of files for different backup/archive regimes here:

http://www.snell-pym.org.uk/archives/2008/07/11/backups-and-archives/

http://article.gmane.org/gmane.comp.version-control.monotone.devel/3264

And, from a user-interface perspective, having to tell the VCS about renames by hand is awkward at times. It'd be interesting to make a VCS where your working copy wasn't "checked out" per se, but exported from a little daemon via NFS or the like so that the VCS had total knowledge of file operations. It could also provide a virtual directory structure for nice read-only access to past revisions - /vcs/history/200808041119/foo.txt versus /vcs/branches/master/foo.txt etc.

What I am finding tricky is finding out which ones use a content-addressable store under the hood as opposed to a revision tree. Is git actually the only one? I know that Subversion (and, therefore, its distributed-operation wrapper svk) and Mercurial do, but digging into the depths of systems to find out how they work at the bottom level is a slow process.

Content-addressable storage is really brilliant for append-only filesystems; it's efficient and simple, and everything in the store comes with a free Merkle tree hash.

Looking at your list of systems, I can't seen any significant omissions. If you do decide to switch to using an existing distributed revision-control system, you almost certainly want to be using one of the ones you mention.

"If I do decide to switch to using an existing..." Are you daring me to write my own? Are you? Are you?