Monotone analysis

[Richard Laager]

On Wed, 2008-07-09 at 20:39 -0500, Gary Kramlich wrote:
> I sent a couple of patches, and I received some comments, so I was
> > expected to modify the patches, isn't that mutating the history?
> > Imagine the patches where in my mtn repository, and somehow I'm able
> > to fix them, and send them again. The maintainers shouldn't care about
> > how the patches where created, just that they are ok.
> 
> If the patch was provided as a pull from your database that you served
> via mtn serve for us to grab the revs

Here's how I imagine this working (using Felipe as a hypothetical new
contributor and me as the hypothetical developer reviewing his code):

     1. Felipe says, "I hate that Pidgin does/doesn't do X. I'm going to
        fix that. He checks out Pidgin. (Ideally a shallow checkout
        should be an option.)
     2. Felipe writes some rockin' code, committing to a branch he
        created for the purpose as he goes. This is `vcs commit -b
        new_branch` initially and `vcs commit` later.
     3. He pushes his branch to somewhere like Launchpad, for example.
        Please don't hate on me if you don't like Launchpad in
        particular, it's just an example. Launchpad sends an e-mail to
        people interested in such things (individually subscribed or by
        team or a mailing list or whatever). I'm one of those people. I
        click a link to view the diff. (Ideally, it would be against
        trunk if it merged cleanly, otherwise against the last revision
        that it merged cleanly against. Super-ideally, it would have
        done a test compile and I wouldn't have to see it if it didn't
        compile and pass make check, but we're not there yet.)
     4. I like the code, but suggest a few changes (via the web
        interface or e-mail or whatever). This communication is logged
        with the branch, sent to Felipe, and it's marked pending or
        whatever so we know it's been reviewed.
     5. Felipe sees my comments and addresses them with code changes. He
        makes more commits and when he's ready, he pushes again.
     6. I get a new notification. I like the changes. I merge the branch
        to trunk.

Now, you'll notice in this work-flow that I only reviewed diffs from
trunk at certain states. This is what happened in the past, where people
would use cvs diff and mail in a patch. This is in effect what is
happening with a git-rebase and a diff. In Monotone, you'd have a
propagate and a diff. (For our hypothetical code review service like
Launchpad, it could be doing an explicit_merge bisect if the patch
didn't apply cleanly.) Anyway, it's all the same effect from a review
stand-point, and this is what Linus (and every reviewer) wants (make
other people to clean it up as much as possible).

However, with a non-mutable history, I can see all the steps in the
middle, if I want to see how the code developed. If I don't care, I just
don't look at that.

Now, once it's merged, if you're looking at branches on trunk, you see
the merge, which should have a changelog of something like: "Merge in
code from Felipe to do X." The diff from that revision against its
parent on trunk is the clean net diff that you'd get from the
traditional diff & mail process or from git-rebase. However, all the
real history is there as well, if you care to follow the tree up the
other parent.

Monotone lacks the hosting service and the shallow checkouts. git and
bzr, from what I read, have those (though Launchpad is closer to this
idea than a generic git host), but they lack a native way to represent
things like the test case passing, but I'm not sure that matters
(because the hosting service could store that separately anyway).

Richard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://pidgin.im/pipermail/devel/attachments/20080709/75b707df/attachment.sig>