top-down version control design
People are artificially restricting the design by accepting the same
“boundaries” as CVS, leaving bugzilla, email, an IDE, mailing lists,
etc. all out of scope and with a fixed relationship to the version
Recent funny-because-its-true bad joke from Red Hat exec David Burney:
Q: How many designers does it take to replace a light bulb? A: Does it have to be a light bulb?
“Does it have to be a light bulb?” is the right question here. The
design space is best taken as something like “a system for maintaining
an open source project,” not “a version control system.”
If someone submits a patch, I should be able to just click “apply to
HEAD” and it’s done. It shouldn’t be about getting a clean checkout,
downloading patch from bugzilla to local drive, applying patch
(figuring out which patch options the person used), creating the
commit message, etc. Should be just one click.
Looking at all the open source version control systems out there, I
don’t really see why they improve my life significantly over CVS. But
if one of them addressed the overall workflow like this I would
absolutely be interested.
(This post was originally found at http://log.ometer.com/2005-08.html#10)