Monotone analysis

[Richard Laager]

On Fri, 2008-07-11 at 02:38 +0300, Felipe Contreras wrote:
> A branch in git is merely a pointer.

Likewise in MTN.

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

Likewise.

> 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 ..."


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

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.

> I saw the code in tailor, and I tried to improve it, however the
> design is flawed. Trying to make it replicate the exact topology would
> require to make it tailor2; a completely different tool.

From what little I know about it, I'd probably agree. I think they
removed the ability to go from a DVCS -> DVCS and keep the structure
some time ago (presumably it didn't work well or something).

> Also, it
> doesn't even work for the simplistic use-case that it's supposedly
> supporting right now, at least with git.

In my experience (and I realize yours may have differed), it generally
works pretty well, as long as you're willing to linearize history
completely (which sucks, I agree).

> Besides, there's no reason for such a tool, there are much more
> effective tools to communicate between git-bzr, git-svn, bzr-git,
> bzr-svn, git-cvs and bzr-cvs. I don't see the point of tailor.

The point of tailor would be to avoid having to write N^2 tools (one for
each pair). I'm not saying that is or isn't achievable or the most
efficient way to do things, but that's the design goal.

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/20080711/488679a2/attachment.sig>