I’ve Killed Subversion

Version control software was created to help programmers keep track of their code. All it does is let you see the version of a document as it existed at any point along the commit chain. (It’s like Vista’s restore points except on a per-file basis, so more complex to use, but hella powerful for managing data.)

Back in the ’90s, I put my websites in CVS. CVS is old school programmer black magic. If you wanted to move files around and not break them away from their history, you had to go in and hand edit these little text databases.

It worked, but there was a real need for a stronger tool, so along came Subversion. It supported moving files and fixed alot of the problems with CVS. It is still based on the idea of a central repository though, one place that everyone syncs to.

Thus the motivation for DVCS. These systems do away with the idea of a single official copy and make it easier for projects to branch apart and come back together. Essentially each party has their own copy of all the documents that they are interested in and they can merge their changes into anyone else’s document stream.

The network under Tip just takes those document streams that are currently siloed and makes it easy to find them. There’s then a workflow for filtering documents.

It creates a very different sort of ecosystem for using the computer. Imagine, for example, that everytime a person creates a font (or improves their font) it goes out to every computer. Imagine that you don’t have to e-mail your co-worker and check on the status of a document because you are able to see the current saved state of their copy. I think it may well prove to be a much easier way of managing workflow.

To get it to work though I am essentially taking my sites that I moved from CVS to Subversion years ago, getting the data all squared away in Subversion and then migrating to Git which is the DVCS I plan on building Tip on top of.

The problem is I’ve already started to do weird stuff and I seem to have killed Subversion. Subversion commits are atomic, meaning that if I change five different pages in a site and then commit them, either all five will go through successfully or all five will fail. There is no middle ground where only three or four are changed and one isn’t.

Sometimes, if there is a hiccup while committing a changeset, Subversion will have a problem. As I was committing, I just got this text:

svn: Error bumping revisions post-commit (details follow):
svn: In directory '/home/will/projects/Tip/plugin/src/chrome/content'
svn: Error processing command 'committed' in '/home/will/projects/Tip/plugin/src/chrome/content'
svn: Error replacing text-base of '...'
svn: Can't open file '/home/will/projects/Tip/plugin/src/chrome/content/...': No such file or directory

In every directory there are a couple “special” subdirectories that always exist. ‘.’ is the current directory while ‘..’ is the directory above. I’ve added a new entry ‘…’ which is the user absolute root. ‘/’ is the system absolute root which is essentially the system administrator’s namespace. ‘…’ is different because it holds files that are independent of the system, but which are in the user’s namespace.

For example, javascript libraries are one way of making pretty pages quickly that work across browsers. Each time you use a script though you need to specify in the page that the script should be loaded. There’s a tag:

<script type=”text/javascript” src=”jquery.compressed.js” />

When the browser reads that it knows to go back and get that file from the server and run it. It will ask for that file relative to the place it found the original file though. In Tip, however, there is the url ‘…’ that is the same for all the sites, so I can put

<script type=”text/javascript” src=”…/lib/JQuery/1.3.2/compressed/js” />

On any page and it will work. In the actual working version of Tip, that file would be linked to the live development tree of the jQuery, so they know what pages are using their code and I know when they make a change.

Anyhow, that ‘…’ directory now seems to have caused Subversion to die. There is code for cleaning up problems in Subversion, but this is what happens when I try to execute it:

will@ebene:~$ svn cleanup
svn: In directory 'media/document/recipe/country/Mauritania'
svn: Error processing command 'committed' in 'media/document/recipe/country/Mauritania'
svn: Working copy 'media/document/recipe/country' locked
svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for details)

Ok, I gotta go figure this out…