[oe] Reconsidering the work flow and how the SCM system fits in
zecke at selfish.org
Tue Mar 11 13:25:55 CET 2008
On Tuesday 11 March 2008 12:21:03 Koen Kooi wrote:
> Holger Freyther schreef:
> | On Tuesday 11 March 2008 11:38:07 Koen Kooi wrote:
> |> Graeme Gregory schreef:
> |> * track .dev: mtn propagate org.openembedded.dev
> |> org.openmoko.needmorebru
> | Non content conflict. ugh! What to do now?
> Since the delta between the two branches is not more than a few
> days/revisions it's easy to find out what happened and move conflict out
> of the way in your branch, finish the merge and if needed reapply a diff
You can not make this assumption of few days/revs and even in a few days/revs
one can create many non content conflicts.
Move the conflict out means:
-Finding the file with mtn au
-Moving it on one side of the branch
-Merge again and then are done or back to the first item for each non content
conflict. This adds artificial history, is complicated and stupid and all my
monkeys are busy doing stuff so I would have to do this...
I want something were this is easy to do. With git I know it is possible (if
you know to use git-mergetool....). With mtn it is not hard, it is
impossible, so I can not use branches with mtn nor encourage anyone to do so.
Specially with my webkit development in a git you start to love cheap, short
lived feature branches.
> The non-content conflict handling is absolutely atrocious in monotone,
> and the monotone devs aren't doing anything to make it easier (they
> changed the error message to offer some more test) because they never
> have such conflicts. Which stinks, because we *do* have them.
Small excercise: try to merge .dev with .dreambox with mtn and git, see which
one is barfing out with non obvious error messages (hint: in this case it is
> But what I'm trying to get at, and doesn't seem to be getting through,
> is that our problems are being caused by people not knowing (and not
> wanting to know!) the limitations (quirks/bugs/etc) of the tools they
> are using. With monotone we are relatively safe, since short of using
> the sqlite3 tool we can't loose data or history when there is a cock-up.
> I fear that with other tools that weren't written with data retention in
> mind (git) we will lose a big chunk of history every now and then
> because someone typed git-quxl instead of git-qux1.
With QtWebKit we had a machine with bad memory, on checkouts certain errors
started to happen. Know what? They were catched on checkout, we had the
objects distributed anyway, so the checksums (even if not for crypto) are
More information about the Openembedded-devel