Links

Ben Laurie blathering


Obliteration

I was talking to FreeBSD’s Robert Watson the other day about version control and FreeBSD’s requirements. Two things emerged that I found quite fascinating.

The first is that FreeBSD has long used Perforce (a commercial version control system) as its “main” version control system – CVS is slaved to it. Of course, FreeBSD is a free software project, so that choice of VCS is interesting. Apparently the core reason is branch management. Firstly, if you try to branch the FreeBSD tree (which is, of course, huge) in CVS, then your machine goes away for a couple of months. Literally. Secondly, CVS doesn’t really understand branches. You can’t continuously merge branch A into branch B – which you can in Perforce. Back when Perforce was selected to replace CVS, there weren’t really any other free VCSes, btw.

Secondly, FreeBSD, being right-thinking people, are thinking about moving back to an open source VCS, now that so many are available. I was interested to discover that a key stumbling block is “obliteration”: when someone commits something they shouldn’t have to the tree often it is good enough to later delete it. But sometimes there is an insistence that the offending material should not just be removed from the head of the tree, but should be completely obliterated from the repository – preventing its recovery from the VCS at all. Not surprisingly, many VCSes do not support obliteration, since the concept is diametrically opposed to a core requirement for version control, namely that I should always be able to recover the tree as it appeared at any point in the past. Perforce, I am told, supports obliteration, and CVS can be persuaded to do it (anyone who’s run a CVS repo will know you can do this by blowing away the corresponding file in the repo itself: ugly, but it works).

Its interesting to think through what obliteration does to a version control system. One obvious consequence is that if you try to retrieve the tree at any point in the period spanned by the obliteration, then you will not get a complete tree back. In a perfect VCS, what would one do about this? I guess you’d have to allow editing of history to permit the tree to be put back “the way it should have been”.

Sometimes its architecturally difficult for the VCS to accomodate obliteration, too. Monotone, for example, expects to always be able to reconstruct a hash chain back to the beginning of time. If you obliterate a file, its ability to construct that chain has gone. Of course, workarounds for this are easy to think of: one could, for instance, include a proxy for the obliterated file which just said what its hash used to be (note that if we ever lose preimage resistance for hash functions this could prove to be a conundrum!).

1 Comment

  1. FYI, the Subversion way to do obliteration is like this:

    1. convert your repository to its textual form: svnadmin dump
    2. edit this text to remove the offending file/path. This is made more convenient by the existence of the svndumpfilter program.
    3. re-create your repository from this edited text representation.

    Not quick or easy, but possible.

    Comment by davidb — 4 Nov 2006 @ 17:27

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress