Monotone analysis

[Felipe Contreras]

2008/7/11 Richard Laager <rlaager at wiktel.com>:
> On Fri, 2008-07-11 at 02:38 +0300, Felipe Contreras wrote:
>> A branch in git is merely a pointer.
>
> Likewise in MTN.

By pointer I meant a single pointer, to a single commit.

In mtn a branch is a bunch of commits that have a tag on them, a cert.

>> When you remove a branch you remove the pointer, not the commits in the branch.
>
> Likewise.

Except that you can't just drop certs. Once pushed the branches stay
there. You can hide them, by adding another cert to the heads, but
they stay there.

>> You can consider a removed branch a suspended branch, it's hidden. If
>> you want to resume work on that branch you can create a new one, with
>> the same name, pointing to the same commit, so it's exactly the same
>> branch.
>
> Likewise.
>
>> I believe what you call propagate is simply a merge. In git there's no
>> distinction between merging and propagating, it's called merge. If you
>> continue to work on it or not it doesn't matter.
>
> Likewise in Monotone. You can use explicit_merge if you want. The
> propagate command is just UI sugar ("porcelain").
>
> mtn propagate $source $dest ==
>        mtn explicit_merge h:$source h:$dest $dest \
>                -m "propagate from branch ..."

But there's a mental distinction. That's why I used the word "call". I
was trying to make clear that the use-case Gary was mentioning was a
common usage of branches in git; a merge.

> The above are all examples of where you simply don't understand
> Monotone.

Why? Because I assumed branches in mtn are not pointers? (they
aren't). Or is it because I said, correctly, that a propagation is a
merge?

> I find it funny that you've railed against all the *good* parts of
> Monotone while missing the actual limitations that the rest of us have
> pointed out before.
>
> If you object to "mtn merge" and "mtn explicit_merge" being separate, I
> would support suggesting to the Monotone developers that explicit_merge
> be renamed to merge and if called with no arguments, it assumes
> arguments based on the current working copy to get the same results as
> "mtn merge" does now.

That's not a limitation, it's just cosmetics. It would be nice if that
gets implemented, but I wouldn't base a choice of SCM based on that.

</snip>

-- 
Felipe Contreras