[oe] Reconsidering the work flow and how the SCM system fits in

[Holger Freyther]

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

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
	-Comitting it
	-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 
mtn)


> 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 
pretty good.