Has anyone ever taken a look at the AEGIS version control system? It
allows a programmer to submit a change to the system which gets sent to a
patch integrator person who then either accepts it and integrates it into
the main line or rejects it and it gets sent back to the programmer with
an explanation of why it was rejected. Also the AEGIS system REQUIRES a
regression test that proves that the change does what it says it did.
Sounds very similar to what everyone is discussing here.
- David Summers
On Thu, 7 Feb 2002, Sean Russell wrote:
> -----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
>
>
--
David Wayne Summers "Linux: Because reboots are for upgrades!"
david_at_summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = C0 E0 4F 50 DD A9 B6 2B 60 A1 31 7E D2 28 6D A8
---------------------------------------------------------------------
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