SJS's Journal: Version Control Tools

Recently I had an interesting discussion about version-control features. One feature that's frequently brought up is "file renames", and that's a feature that I just can't seem to see my way to considering all that useful.

First, if you're renaming a lot of files, it means you didn't do much thinking about your code before you started. As that seems to be the way of things these days (thinking ahead is hard and should be avoided, it seems), however, that's hardly much of an objection.

Second, how do you puzzle out cycles?

Consider a version control tool -- vct -- that supports a "rename" capability. And further, consider two files, A, and B, that might be renamed.

% ls
A B
% vct rename B C
% ls
A C
% vct rename A B
% ls
B C
% vct rename C A
% ls
A B
%

We've just swapped two files. When we look at the history of "A", do we see the thread back to B, or do we see that A was removed and later replaced with B? It seems that BOTH bits of information are important, depending on the question being asked.

Lather, rinse, repeat. The history becomes terribly convoluted. Obviously, we need a "swap" capability as well. . . which leads us to:

Third, a file rename is only the simplest form -- what about splits, swaps, and refactorings?

If we buy that renaming is an important operation for a version-control tool to support, we can't stop there. As we've seen, a swap operation CAN be composed of several renames, but that's not efficient. Therefore, we're compelled to clamor for file-swap support.

But it doesn't stop there.

More often than file renaming, we have splitting. A file gets just too big, or perhaps it encapsulates two relatively independent concepts, so we split out the functions/methods/whatnot into two or more files. You don't necessarily rename the file, you just copy it and delete all the bits out that are in the other file, and vice-versa. We record this in the version-control system by saying something like "Extracted -related methods into ." -- obviously, that's not good enough. We need to add in an "extract" capability.

Along those lines, there's the refactoring operations that ought to be supported. Many refactorings are along the lines of "extract code", and surely this should be tracked by the version-control tool explicitly, rather than relying on the user to remember to correctly document what was changed and where. Some of the 'extraction' operations aren't quite that simple, however...say, the extracting of an interface from a class.

So the various refactorings need to be supported. We can see that "extract_interface", "extract_superclass", "extract_abstract_class", "push_method_up", "push_method_down", "move_method", etc. etc. will be capabilities that need to be programmed into our version-control tool. And since the list of possible refactorings isn't all that static, we'll want to have a team to keep up with the refactoring community so that the version-control tool can keep up. Or we make our tool pluggable so that all someone needs to do is to write a plug-in to handle the NEW sort of operation.

Of course, the tool is now so awkward and difficult to use, we'll have to invent a process to manage everything. Otherwise those pesky developers will just go back to making changes and annotating what they did when they commit their changes, rather than using the many useful options our tool provides them.

We'll have to do something about that.