Older blog entries for Xorian (starting at number 14)

This warning is one of the funniest things I've seen in some time (details changed to protect the guilty):

src/foo.cc:1234: warning: `DETERMINISM_MODE'
   might be used uninitialized in this function

Well, I tried suggesting that the git people take a look at Vesta, but it seems it's probably too late.

But I'm not bitter or anything.

When I read about git, I was really surprised by how similar it is to the Vesta repository.

  • Linus said "git is not an SCM. it's a filesystem designed to host an SCM". The Vesta repository is a filesystem. It has a versioning system and a builder built on top of it.

  • git stores complete copies of files, but only one copy of each file, just like Vesta.

  • git's backing store is indexed by a hash of the file contents, just like Vesta's.

Coming off BK, I would have expected Linus to go in a direction closer to Darcs or Codeville.

Of course as a developer working in the same space, it's frustrating to watch so much effort going into starting yet another new version control system. Even more so when it seems so close to what Vesta's been doing for almost a decade.

1 Mar 2005 (updated 1 Mar 2005 at 22:32 UTC) »

My Mac mini finally arrived last Thursday. What were the first things I did with it? Enable incoming ssh, install the development tools, and modify the code needed to get the Vesta repository mounting on Darwin. This only required minor changes over the FreeBSD version I wrote earlier. It's getting easier with each new OS.

Unfortunately, as I've long pledged to port to Solaris first, I may not make a lot of progress on the MacOS X port for a while.

CodeCon musings

Aside from being a lot of fun and exposing me to new work people are doing, CodeCon gave me the opportunity to have interesting conversations about Vesta and consider how it relates to other projects.

While listening to Walter Landry's presentation on ArX, I compiled a list of a few good things about Vesta which I haven't included in presentations about it before (some stolen directly from Walter's presentation as they apply to Vesta as well):

  • Disconnected hacking. You can make a local branch when not connected to the network. [I do this on my laptop when traveling, and this is in fact how I was working when visiting Microsoft Research.]
  • Strangers can make changes without the main developers giving permission. With only read access to a central repository, you can make first class branches in your own repository. [This is related to the previous point, in that it all happens locally after replicating whatever version you're basing your changes on.]
  • It doesn't use timestamps for anything. Like many modern build systems, Vesta does not use timestamps for dependencies. Unlike most modern competitors, it doesn't depend on timestamps as a versioning system either. Since it is its own filesystem it knows whether you have changed a file.
  • It doesn't intermix its data with your source files. Most versioning systems store some meta-data about what you're versioning in files/directories intermixed with your sources. Because Vesta is its own filesystem it can store that meta-data in special directory attributes. This keeps its data out of your way.

I talked with Ross Cohen (who works on Codeville) about merge algorithms. He told me stories of crazy repeated merge cases that he thought would never come up in practice, and then did. I asked him if he'd be offended if I ripped off his merge code for the pluggable merge architecture I've been designing, and he said he wouldn't. (I'm trying to avoid getting into the business of writing a new merge algorithm.)

I talked to Nick Mathewson and Roger Dingledine from the Free Haven project about securing Vesta. They suggested I write an RFC-style protocol spec if I want anyone with a security background to help. They also confirmed my concern that the mastership transfer protocol is the most problematic part, as it uses TCP connections in both directions between the peer repositories. To a lesser extent, replicating from a satellite repository back to a central one when checking in after a remote checkout has the same problem. If we could find a way to make these active connections passive, it would also help people behind firewalls.

Kevin Burton from rojo.com recommended including more information in the RSS feed of latest versions in the pub.vestasys.org repository. I've been having my feed generator trim the checkin comments, but he said the RSS client should do that. He also suggested including a diff in the feed.

Zooko and I talked briefly about merging. Specifically we talked about how

"smart" merge algorithms need more information than a common ancestor and two versions descended from it. They typically take into account more about the steps between the common ancestor and those two versions. I said that I thought it should be possible to use the trigger mechanism I've been working on to record the kind of extra information such algorithms would need. He contended that without spending time using and studying a system with smart merging, I won't know quite how to design to enable it. While I have read through the Darcs "theory of patches", I don't see myself having time to spend really getting a lot of experience with another system.

Andy Iverson (?) and I talked about Vesta's approach of storing complete copies of all versions. He brought up the example of how small a BitKeeper repository is with the entire Linux kernel history. I asked "Is having that entire history really interesting?" He contended that it is, bringing up the example of searching through the history to find when some feature/variable/function was introduced. This probably has to do with the fact that the design decision to store complete copies was made early in Vesta's design (in the late '80s), before open source really took off. Basically the argument was "disk is cheap, programmers aren't typing any faster." However, open source projects can scale to a much larger number of programmers making a much larger number of changes. The Vesta developers couldn't have predicted this effect when they made that design decision. We could do something to add compression of versions, but I'm wary of doing that for performance reasons, at least at the moment. One of Vesta's selling points is O(1) checkout/checkin/branch and access to existing versions, which we would lose with compression. Also, adding compression right now would put load on a central resource (the repository server). I have some ideas on splitting up the system in ways that would make it possible to distribute this load, but I don't expect to make progress on that in the immediate future. Lastly, the Linux kernel clearly has a higher number of contributors (and probably a higher rate of change) than most projects, so maybe this is only an issue in extreme cases. I should probably spend some time measuring the storage requirements for the history of different free software projects.

12 Feb 2005 (updated 13 Feb 2005 at 23:51 UTC) »

While at CodeCon, wmf told me about Electric Cloud.

I've been reading through their technology description, and I have to say it sounds like they've just re-implemented a small portion of Vesta. Their dependency detection mechanism sounds almost exactly like Vesta's (and for that matter ClearCase's). The only thing which sounds new to me is that they fire off many build pieces in parallel without knowing whether they're doing them in the right order. If it turns out that they did some build steps in the wrong order, they re-execute those portions. This approach sounds dumb to me. Why not just do it in the right order every time (which is what Vesta does)?

Even worse is that they call their tool "plug compatible with make". So they're working really hard trying to take an old, known broken model and beat it into something scalable without redesigning it at all. Great idea.

Now how to I tell the USPTO that I have prior art for their "patent-pending automatic conflict detection and correction technology"...

On my last day visitng Microsoft Research, I wore my O'Really "Writing Word Macro Viruses" t-shirt. I was highly amused, and nobody at MS seemed to notice.

I feel I should start this entry by saying: I am not making this up.

I've spent the last two days, and I will also spend tomorrow, having what I consider to be a unique and somewhat strange experience. I've been visiting Microsoft research. What's remarkable about this is that I was invited there by employees of Microsoft research to work with them on the free software project I work on. Yes, that's right, Microsoft invited me to visit them so that they could help improve a piece of free software.

But wait, it gets better. This piece of free software is, at least in its current form, UNIX only. (chroot plays a key role in the implementation, and AFAIK Windows has no analogous function.) In other words, Microsoft invited me to visit them so that they could help improve a piece of free software which doesn't even run on Windows.

Now don't worry, the world has not gone mad, there is a logical explanation. The software in question was developed as a research project at the (now defunct) Digital/Compaq Systems Research Center. Some of the original developers (including the team leader), now work at Microsoft research. So really they have just offered to spend a few days helping me understand and improve a few tricky parts of the implementation of something they built before they worked for Microsoft, which just happens to have become free software.

But still, when I actually think about what I've been doing the past two days, it seems rather improbable.

I'm flying from snowy Massachusetts to sunny California tomorrow. After working through the middle of the week, I'll be going to this year's CodeCon, which I'm looking forward to.

Before heading out, I decided to write the code needed to get the Vesta repository mounting on FreeBSD. Luckily, it was far easier than what I had to do for Solaris.

I saw a presentation on Pin yesterday. It's pretty neat.

I've been working on instrumenting multi-threaded server appliactions to do performance analysis for the project I work on, but it's a bit of a pain. It would be nice to be able to dynamically attach the instrumentation to a running server without rebuilding or restarting it. It looks like Pin would be able to do that, though its multi-threading support is still in beta.

5 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!