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

[Justin Patrin]

On Thu, May 1, 2008 at 3:20 PM, Justin Patrin <address@hidden> wrote:
> On Thu, May 1, 2008 at 2:59 PM, Bruce Stephens
>  <address@hidden> wrote:
>  > "Justin Patrin" <address@hidden> writes:
>  >
>  >  > It seems that some of the folks at OpenEmbedded are now grumbling
>  >  > about use of monotone again and that some of our key developers are
>  >  > looking to switch to something else (hg or git)[1]. The main point
>  >  > of contention seems to revolve around, as we've seem lately on this
>  >  > list, getting rid of revisions. In this particular case a revision
>  >  > had been distributed that made unwanted changes. It was a head
>  >  > revision and was suspended by a developer but other developers who
>  >  > had versions of monotone prior to the suspend functionality blindly
>  >  > merged it with their code, causing a chain of suspensions/removals
>  >  > that was eventually fixed with a reverse patch.
>  >
>  >  So how, concretely, would this have played out better had OpenEmbedded
>  >  been using either hg or git?
>  >
>
>  That I don't know, I just thought I'd let you know that there's a
>  chance for discussion. I think that people have more of a feeling of
>  control with the other systems. I honestly don't know enough about hg
>  or git to comment on how they might solve this problem.
>

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.

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.

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.

-- 
Justin Patrin