2009-12-02
The problem with the OpenSolaris source repository
It's nice that Sun has provided the OpenSolaris source in the form of a VCS repository, but in many ways it's not terribly useful. The problem with it is that the OpenSolaris repo is not a working repository.
By that I mean that it is not what the Sun developers actually work in; instead it is essentially a series of code snapshots converted to a repository. It's nice that we get a sequence of snapshots in a convenient form, and it's nice that it happens relatively often, but it means that examining the repository history is often mostly pointless; the history in no way represents what actually happened during development, and it's common that multiple changes were merged together into one commit.
It would be reasonably okay to pretend that OpenSolaris has only a single line of development, without branches and merges; there is something to be said for keeping your public history simple and thus forcing developers to rebase often and submit clean final changes (generally no one cares about how your change evolved over time, they just care about the final form). But there's no excuse for merging changes together in commits; it just makes it hard for outside people to look at specific fixes, either for commentary or for cherry-picking, and it complicates attempts to bisect for failures, which is a valuable feature if you want outside testing.
(There is also an appearance issue. When the repository you expose to outside people is clearly not your working repository, you are openly advertising that there are first class and second class citizens and the first class citizens get better tools.)
Sidebar: an example of a multi-change commit
In case you're in doubt about those multi-change commit, here's a random example. This is commit acbd69cd0179 (aka commit 11207):
6663229 cw enters infinite loop if fork failed
6663216 cw(1) incorrectly refers to SOS10
6414843 SUNWonbld shouldn't install sgml man pages
6414845 groff reports warnings in SUNWonbld man pages
(Some but not all multi-change commits seem to at least be for the same program or library or area of the kernel. This is not one of those, except vaguely.)
The mixed directory/unrelated files VCS problem
To follow up an earlier entry, one might sensibly ask
what the problem is with using a modern, whole-directory version control
system on a directory full of unrelated files, the classical example
being /etc.
What you effectively have in this situation is a directory with multiple 'modules' (files and groups of files) that are logically separate and independent from each other. As they're separate modules, these files usually evolve and are developed at least somewhat independently. Putting all of these files into a single repository creates a mess in the same way that developing several different bugfixes at the same time in the same source code repository does.
As with source code, what you wind up with is a repository that can give you time-based snapshots of the state of your directory, but doesn't tell you very much about the logic of development of various things, at least not in a straightforward way. (You can sort of reconstruct it by restricting various repository operations to just a subset of the files, but you are working outside of things.)
This mess gets worse if you need to synchronize changes across multiple machines. Here, you really have the classic entangled changesets problem, especially since not all 'modules' may apply to a particular system. Updating a system to the current state of, say, your overall NTP configuration becomes a non-trivial operation because you're fighting how the VCS wants you to work.
With some VCSes (eg, git) I think you could cheat madly and sort of make this work, but I also think that you'd wind up with a lot of heartburn. With others, I don't see how to make this work short of having completely separate repositories for each machine and just shipping patches around by hand.
(Okay, I suppose there are various cherry-picking and transplanting extensions for various VCSes, but I suspect that significant use of them will wind up with an increasingly horribly tangled repository history.)