August 2007

Nicholas describes the process and results of computer programming:

“It's sort of like you're a combination architect / builder, but you're a really terrible one. Someone asks you to build a new bathroom for their house, so you do, but despite all your careful planning the finished product is just shite. For example, the shower wall is made out of soap, because you thought it would be convenient — now nobody needs to buy soap, because they can just rub up and down against the wall for a bit and then hose themselves off (you installed a hose instead of a shower head for greater flexibility).”

It's worth reading the full piece.

Matthew Palmer argues against “having your revision control system assume that patches which are the same text is the same”:

If you think this is right, "think about two different patches each adding a new keyword and also changing the line ``#define NUM_OF_KEYWORDS 17'' to ``#define NUM_OF_KEYWORDS 18''." (example taken from the darcs manual, because I'm not going to come up with a better example than that).

In the example he cites, there will most likely be a conflict, assuming the added keywords are different (and depending on what the source changes to add keywords look like, but the obvious schemes would cause a conflict). The conflict will be at the point where the different keywords are added, rather than at the “#define NUM_OF_KEYWORDS”, but the human resolving that conflict would, if your source is clear, know that they need to check the NUM_OF_KEYWORDS value too. (Although if your source code has the property that you need to update multiple places to register one new thing, it's violating “Don't Repeat Yourself” principle, but that's another discussion...)

But more significantly, there are plenty of ways that two patches that don't conflict textually can conflict semantically. One patch might change the signature of a function, and another may add a new caller of that function that assumes it has the old signature. And there's lots of more subtle ways that they could conflict.

If you want to ensure your code is correct in the face of changes, then the tool for the job isn't a Version Control System. It's a Test Suite, preferably an automated one. Version Control Systems help you collaborate and manage changes, but it's your Test Suite that tells you if the code still works.