[Monotone-devel] Re: OpenEmbedded looking to jump ship

[Bruce Stephens]

"Justin Patrin" <address@hidden> writes:

[...]

> It looks like the original discussion is here:
> http://projects.linuxtogo.org/pipermail/openembedded-devel/2008-March/004642.html
> I haven't been reading my mail very carefully lately.
>
> The majority of complaints seem to be that "merge is broken". I
> honestly can't understand this argument. Merge in monotone has
> always been the part that makes the most sense to me. It seems
> likely that the people who say that mtn's merge is broken are not
> paying sufficient attention to what they're doing (such as
> fragmenting history by copying files, then renaming back to the
> original name).  Most people seem to be having non-content
> conflicts, which, I must agree, is a part of monotone that is
> lacking in UI. Being able to suture 2 technically different
> files/nodes into one in a merge would help a lot here.

Also I suspect workspace-merge would be valued.

> There also seems to be a want for cherry-picking, although I'm not
> sure how this works in practice in other SCMs. Using pluck can
> cherry-pick revisions just fine but it's just more likely to cause
> non-content conflicts down the line.

AFAIK GNU Arch and darcs have really different support for
cherry-picking (and maybe subversion 1.5, if it's ever released).  I
think other systems do it much the same as monotone.  With git this
doesn't cause a problem with non-content conflicts, of course.

> Still others appear to want to be able to merge local revisions into
> one before pushing....although it sounds to me like this is more a
> side-effect of how git works.

Having used git for a few months now, I'd urge you not to dismiss this
kind of thing.  Depending on your workflow it can be enormously
valuable, and I think I wouldn't want to give it up, now.  Similarly
git's way of doing branches (which lets you create a branch for a 10
minute reorganisation and then remove it when you're done, without
worrying about its name clashing with anything else (because it's
going to go))---both are very convenient.

Not necessarily easily transplantable to monotone, but not merely
side-effects of how git works.

But yeah, that's how I'd summarise the issues reported:

        non-content conflicts

        awkward merging generally (presumably wanting workspace-merge)

        some (less clearly defined) annoyances with branches