The Basics

Remember that Chet and I use a little code manager that we wrote in Ruby, that runs in the background as we code. It just watches for files that change in the source directory, and when they change, it copies them to an archive subdirectory. Each file is given a unique name based on the time it was saved, such as:

TestTextModel.cs.20021124152803
TestTextModel.cs.20021124154648
TestTextModel.cs.20021124155349

Those names will make more sense if you think of them as saying something like this:

TestTextModel.cs.2002/11/24 15:28:03

Each file just gets copied, with a new extension representing the date and time it was last modified

You may be wondering why we don't build a complex file structure, or save deltas instead of the whole file. The short answers are:

1. We don't need the complexity yet. Having the files all in one directory works and it's easy.
2. Deltas are largely about saving storage. We're not worried about that. If it becomes a problem, we plan to address it then.

What's Next?

In a previous article, we mentioned that the next thing might be a simple GUI that let us click back by date and time, and put everything back the way it was. We think that might be tricky, but it seems like a good next step. Here are some other ideas for useful things to do:

• Go Back. Click one button, and all the most recent changes (just the last consistent batch) are backed out. This would be good when we go down a rathole and have to get back out. Today we do that with a bunch of Control Zs, but we have to remember which files have changed.
• Log Red Bar / Green Bar in NUnit. Suppose that every time we ran NUnit, it added a log record to a file, stating date, time and whether the tests were Red or Green. That information could be used in the file-restore GUI, to take us back to a good place, not just the last place.
• Go Back to Last Green Bar. Now this would be cool. When we go down a rathole, it would take us back to the last time everything was known good. Just a more powerful version of "Go Back".
• Go Back to Green Code, Red Tests. Suppose we start at a Green Bar, write a new test, then code off in the wrong direction and can't make it work. We might like to back up all the code to when it was last green, but keep the tests we wrote. This one is a bit harder to do than the others, since it has to recognize test files.

Now all of these ideas may seem kind of goofy to you, so please think about them a bit. (And if they still seem goofy, or you have better ideas, please write.)

Our thinking is this. We're trying to ratchet forward in tiny steps. We start Green, write a test that goes Red, then make it be Green again. Sometimes we mess up in making it Green, and we want to start over. So we use Go Back to Green Code, Red Tests. Then we begin again.

Other times, we start with the wrong test, and then go down a bad path. So we use Go Back to Last Green Bar. Then we write a new test.

The next step along these lines could be one of two. We might just build a little Time Browser that would let us back up to a known time hack. Or, we might modify NUnit so that it logs its results to a file. That would set us up for better knowledge of changes, which we could use in the Time Browser, or even manually.

Further Out

We've also talked about how to use code management when there are multiple machines editing at the same time. XP recommends "Continuous Integration", which basically means that everyone integrates their code as frequently as possible. At first look, it seems like this idea would create lots of conflict, but in fact it does not.

As the system gets larger, it becomes less and less likely that two pairs will be editing the same files. And as pairs integrate more and more frequently, conflicts also become less likely.

So the idea for the XP code manager would be this:

1. Whenever any pair gets a green bar, commit their changes to the repository, in the main line: the line intended for release.
2. Push that code to all other pairs who are editing, unless they are editing the very same files.
3. Handle collisions, ideally, by making all the committed changes to the live files in the other editors. Use some kind of delta operation to avoid stepping on actual edits done by the second team.
4. Ignore the complications and see what happens.

I freely grant that this is radical, and that it might even be a bad idea. But give it some thought and see what you think.

The Overall Vision

I'm not sure if I can express it well enough yet, but here goes:

1. Save every change, just because you can.
2. Be able to back up easily to any consistent state from the past. By consistent I mean all files in a state that they were actually in, not some mixed up situation.
3. Know whether a consistent state was Red or Green. Be able to control backing up to either, or to a state where Red tests have been added but the code is still Green.
4. When code is Green, bring all pairs up to date instantly.

A few folks are working on implementing parts of these ideas. I'll appreciate hearing about experiments, or just reactions. Thanks for listening.