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

[Holger Freyther]

Justin Patrin <papercrane <at> gmail.com> 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.
> 
> 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.
> 

Okay regarding merging and propagating. Non Content Conflicts are a hell. I have
seen way too many errors with manually resolving these conflicts (mtn drop,
throwing away fixes etc), I can not use daggy fixes for parts of OE due this.
mtn is throwing NCC errors with half-way understandable (it got better)
messages, e.g. if you have two files with the same name and different path, mtn
is not telling you which of the files has the conflict, making it worse git
handles these kind of conflicts properly. Different origin, same content, git is
totally cool with that, mtn chokes, which massively gets in my way of doing
development. I have work in a Openmoko branch (because they pay me), which I
would love to cherry-pick into org.openembedded.dev, but I don't because of mtn
and the ncc that would come. With git a lot more of my work would be inside OE.

The recent mtn suspend "issue" really annoyed me. mtn suspend is useless for a
project until you force certain versions of monotone to every user (which you
can't), disapprove does not work for merges (well it would have to create two
heads again, which might be hard... git is more stupid, it just knows revert and
has no multiple heads but cheap branches which you can create at an airport
before entering a plane)...



So what mtn lacks:
    - git-commit --amend
    - git-rebase -i
    - git-add -i
    - git-checkout -b ... (and throwing away branches)
    - git-show (easy with mtn diff... but merges...)
    - git-format-patch (well, do-able with mtn diff again)
    - git-rev-list origin/master.. (to show what I would push upstream)
    - gitk
    - being able to resolve any conflict


What I dislike about mtn. In contrast to git it forces a way of how I should
develop software (I don't like force), and after something entered the database
I'm virtually blind. I don't know which branches got updated, got created during
a pull, I don't know what I'm going to push upstream. With git I use gitk and
git-rev-list to see what changes I would push upstream.

Seriously I'm impressed what you have achieved with mtn, I like most of it, but
in terms of improving the way I develop mtn is getting in my way more and more
often (and it is not the speed).


If you have questions regarding my use-cases, or what I think is broken in mtn,
feel free to ask.

z.