-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello,
I got to thinking about Arch, and the recent discussions about patch
management, and Linus' decision to use Bitkeeper, SCM, and distributed XP
(impossible by the very definition of XP).
Was scm-hackers@regexps.com ever started? This probably isn't the best place
to have a long discussion about the topic, but it /is/ on-topic insofar as my
question at the end of this message is about Subversion, and the rambling
preamble is necessary background.
I understand that Subversion's scope is limited, and I'm wondering if I
should start on a scripting subsystem for Subversion to handle what I'm
thinking of as peer-reviewed commits. I'm also aware of some of the
discussion that has touched on this topic.
I'm thinking of a situation where commits need to be peer reviewed, such
as with the Linux kernel, or indeed Subversion itself. Without a peer
reviewed commit mechanism, you get the dev@subversion list, where people must
generate patches, compose an email and import the patch, submit the patch to
an email system, and (in the worst case), somebody else has to extract the
patch from the email, apply it, and commit it. This is tedious,
counter-productive, and there is only informal structure to the system.
Consider an environment where you want to allow many people commit access,
but at least n other people have to approve of the commit before it goes into
the tree.
A response last week to just this topic was "just use branches". The way I
imagine such a system working is that each developer gets her/his own branch,
which they develop on. Every day, they compare the main branch against a
couple of other developer's branches, approving of and merging the changes
into the main branch. Their changes get similarly approved and added, and
each morning they merge the main trunk into their branch, bringing it
up-to-date. Arguments, reasoning, and justification for the change go where
they /should/ go: in the log message, not in an email, where they get lost.
This works, and has a nice feel to it, but is also missing a couple of
things: a mechanism for rebutting a change, or indeed alerting the submitter
to the fact that his coFde has been reviewed and merged or rebutted. It
would be nice to have a mechanism for trimming down log messages on a merge;
the log message for the final trunk merge would usually a subset of the
message justifying or arguing for a change. On a higher level, there's no
real control over the main trunk, and no voting mechanism; I don't imagine it
would scale well to, for example, use on Subversion itself.
I got to thinking of how Slashdot works, and how that would be a good model
for commit review. Developers would moderate; the system would choose
commits at random and allow the developer to read through and give it a +-1
rating. When a commit reaches a given threshold, in it would go; if there
were any merging conflicts, the submitter would be required to merge the code
by hand. Context could be retained if every developer committed only
discrete changes to the code; then each commit would be self-contained, and
the system could look at each commit by a single developer as a chunk for
review, regardless of how many files it modified. DIE, rather than fixing
something, test it, fix something else, test it, and so on, and commit at the
end of the day, you would fix something, test it, then commit it to your
branch immediately, whereby the system would make it available for review.
I know that this functionality is not within the current scope of Subversion,
but if I were to start writing a system based on Subversion to do this, would
I be wasting my time -- IE, are there already plans for something like this,
is there a better way to do it, etc?
- --
|.. "Macintosh... Proof that a Person can use a Computer all day and
<|> still not know ANYTHING about computers."
/|\ -- anon
/|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8YrL7P0KxygnleI8RAnOfAJ9SnsZe5u6xsn0fpArZnGvuimjDYQCgqfV8
GJZl0SFhbaOhADlDPHa1WZI=
=929d
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:05 2006