The problem with the OpenSolaris source repository

December 2, 2009

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.)


Comments on this page:

From 192.18.43.225 at 2009-12-10 20:22:03:

Actually, the externally accessible repository is a clone of the internal one. We didn't enforce one bugfix per commit in our SCM tool prior to adopting Mercurial and, after much discussion on tools-discuss and scm-migration-dev, elected leave that policy in place. The analyses this choice makes more inconvenient are the cost of that policy; the discussion, however, couldn't justify placing additional cost on the committing developer, who already has a long checklist to run through.

I get the same report on that changeset you do:

3098 rosseau $ hg pull -u                          ~/project/on/repo/onnv-clone
pulling from ssh://onnv.sfbay//export/onnv-clone
searching for changes
adding changesets
adding manifests
adding file changes
added 2310 changesets with 19132 changes to 11051 files
10836 files updated, 0 files merged, 1578 files removed, 0 files unresolved
3099 rosseau $ hg log -r acbd69cd0179              ~/project/on/repo/onnv-clone
changeset:   11207:acbd69cd0179
user:        Peter Dennis - Sustaining Engineer <XXX@XXX>
date:        Mon Nov 30 19:06:24 2009 +0000
description:
	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
	Contributed by Rainer Orth <XXX@XXX>

Cheers
Stephen

Written on 02 December 2009.
« The mixed directory/unrelated files VCS problem
Learning from Unicorn: the accept() thundering herd non-problem »

Page tools: View Source, View Normal.
Search:
Login: Password:

Last modified: Wed Dec 2 23:44:02 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.