Monotone analysis

[Felipe Contreras]

2008/7/10 Richard Laager <rlaager at wiktel.com>:
> 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).

Exactly!

And bzr also supports rebasing.

And both git and bzr support patches natively. So if developers prefer
to review patches by mail once you are doing fixing your commits you
do git-send-email, or bzr push, and the mails are sent automatically.

That is specially useful if the project is using a SCM you don't like.
Many people use bzr-svn or git-svn, they work on their favorite tool,
and nobody needs to notice you have local branches, and you are
reorganizing the commits locally, effectively mutating the history,
but only for you. Once the patches are accepted they enter the
non-mutable history.

What many Pidgin devs don't understand is that people are already
mutating the history in mtn with patch reviews, maybe manually, maybe
with quilt. The only difference with git/bzr is that this reviewing
process can be easier using the SCM tool. And by the way, both git/bzr
have quilt like functionality, in the case of bzr through plugins.

So yeah, you say you have unmutable history because you leave an
important part of the equation out. You can also also do the same with
git; never rebase, and use quilt for patch management, except that
instead of quilt you can use git, for the maintainer it's the same; he
will be receiving patches.

Best regards.

-- 
Felipe Contreras