Ok, so I'm not totally satisfied with any current VCS, and I've got some of my own ideas that I'd like to implement. So I'm putting the ideas here so I can stop thinking about them, at least for tonight, since I have to write a project.

Basically, the first thing we're going to need is a way to store versions of things on disk. So the first thing I'm going to write is a database for objects.

"Objects?" you ask. Yes, objects. Not files, not branches, not revisions, *objects*. It's on top of this database that we'll implement the actual VCS features we need.

Objects can have properties. Each property will either be "mutable" or "immutable". Mutable properties may be changed after they're written to an object; immutable properties may not.

Objects will be identified by their hash (exactly which hash function, I'm not too worried about at the moment, but it's unlikely to be SHA1 ). Objects will be able to describe how they're hashed, but by default, objects will hash themselves by gathering up their immutable properties, sorting based on the name of the property, and hashing the resulting set of properties.

Such a database could easily be implemented, either with an RDBMS or with plain directories. Heck, we could write one with a CDB database if we wanted. A simple network daemon could serve up such a database. As long as the database is implemented in such a way that objects can be atomically committed, and multiple objects can be committed together atomically, the database has done its job.

Believe it or not, this is all the database needs to do. On top of this, we'll be able to build a VCS. We'll have "file" objects, "tree" objects, "changeset" objects, "branch" objects, "certificate" objects, and maybe a few more.

I've gotta go now, the mind-virus is getting too strong, and I just found another paper with ideas to integrate.

Jeremy

It's worth noting that the database will be *entirely* separate from the VCS, so much so that it will be a separate project.

I think I'll name it "HODB." The Hashed Object Database.



Jeremy

For any VCS to be successful, it will have to have an easy way to pull changes from CVS (or at least to import a CVS repository) and will probably need a good way to export to CVS (so people feel comfortable that if they don't like it, they can always go back). I think we should implement this, and once we're using the new VCS, we should use this gateway with SF.net's CVS to keep our activity rating up (for as long as we're using SF.net).

Jeremy

Another quick note about mutable versus immutable properties: mutable properties will be versioned.

That is, if you change a mutable property, the old version isn't lost: instead, there's a new version of your object with that mutable property having a new value.

Jeremy

Is that pronounced "hoe-dee-bee"?

What's an example of an immutable property that would be useful in this system? Filename? Or would that be mutable so as to allow file moves/renames easily?

yup

Jeremy

An immutable property would be "content" in a Revision object--that content of the file at that revision.

A mutable property would be "version"--a nice, human-readable version number. The reason it would have to be mutable is that it would be subject to change: I may develop under the notion that my revision is 1.9, but when I sync with another database, I may find that it already has a 1.9, so either I'll need to update my version property or the database will have to update its version property.

Another mutable property would be the "commit message" property on changesets. That way, if later I find that my commit message is inadequate (typos, missing information, etc. could cause that) I can update it.

Larry McVoy, back when he was starting BK, made an interesting post that I just found last night: http://list-archive.xemacs.org/xemacs-beta/199809/msg00589.html . I think the idea of revisioned changesets is a *powerful* one, and definitely one that we should implement.

Unfortunately, while immutable/versioned-mutable properties sound good on paper, there's a major problem with them in execution: by versioning the mutable properties, we've basically turned the database into a VCS unto itself, having to resolve conflicts between mutable properties just like a versioning system has to resolve conflicts between files. My smartest friend and I thought for a couple hours on this problem last night and were unable to reach a solution; that's not to say that a solution can't be found, just that we haven't yet found it

Jeremy

Oh, okay, I was confusing the timeline for the mutability. You mean mutability within a given changeset (er, object ). Obviously the change itself would be immutable because that's kind of what defines the cha^H^H^Hobject. I guess I just wasn't thinking straight. Sounds cool.