git seems pretty awesome. I haven’t participated in a large team version control system since the 90s though; personally I have just been using rcs directly when I need file-level version control.

But on this topic in general, I have long thought that maintaining a per-object revision history should be a fundamental, automatic, highly granular, low-level feature of.. well, I guess you could say anything you do with digital data. But the problem is that most vc systems deal with files rather than the concepts contained in the file. For software we don’t do revision control of functions or classes, for instance, but rather their source text in ASCII or UTF-8. You can make all kinds of changes to the source text that don’t affect program functionality, but when only operating on the source text, a revison control system cannot tell the difference. This is especially a problem when the concepts migrate among individual files over time. Personally I want to keep track of the objects more than the files.

I frequently find myself wishing that the changes I had made to an individual object, whether it is a function in software or layer in a Photoshop document, could be rolled back independent of the state of everything else. Usually the “undo history” is a document-centric sequence of edits, just as the revision history would be for a text file of source code.

My only experience with highly granular automatic revision control was back in about 1995 when I came across a SunOS file system bug. I was going insane finding recently edited source files zero’d out on block boundaries. I didn’t realize it was a bug until I got in touch with a Sun engineer. Until then I cranked up the regular backups, but in addition, I wrote a small program to frequently poll the stat() modification time of a list of files, and upon finding a change, make a numbered backup copy and automatically check them into rcs, thereby crowding the file system with copies of my files and minimizing the chance of actual data loss. I also thought generally it would be interesting to have the micro-level change history, but when it became thousands of revisions per file, since I habitually save about every few seconds, it was overwhelming. To make automatic revision control work, there has to be some way to decide what is a reasonable change size. I would imagine that over time, the system would have to scan and group versions that are similar. For instance, if something changed ten times in ten seconds, with nothing close before or after, it might be reasonable to group or combine them in some way to unclutter the version history.

This would be a much more intelligent process if the vc system had a structural understanding of the information; multiple sequential changes to a comment could be grouped, whereas a change to a comment followed by the addition of an argument to a function definition probably might not.

So for an inside out system, vc functionality would be a fundamental feature of the system, and information like comments, author, and other metadata would not be part considered part of the code, because they’re simply non-functional. They are attached to the code, related to the code in some way; modifications to a note about the code doesn’t constitute a change to the functional nature of the software.