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

[Leon Woestenberg]

Hello,

On Wed, Mar 12, 2008 at 11:54 PM, Koen Kooi
<koen at dominion.kabel.utwente.nl> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  | Whilst I think OE will always have a central master .dev repository I
>  | see a lot of gain from having branches. I would have happily put the
>  | sysroot changes into a branch and likewise the packaged-staging stuff
>  | I'm working on. As it is I'm keeping it locally uncommitted with no
>  | version tracking since I don't really want to play games with monotone.
>
>  Thank you for saying it right out: "I haven't tried to use branches in
>  mtn, ever".
>
mtn will handle branches, no issue. But how easy can a branch be
merged back if it has been branching off for too long? I guess we end
up in the same situation as the dreambox branch?

Paul, *yes* a head is like a branch in the revision control system,
but I cannot use it as a branch! Unless you can explain me how I could
*easily track or pluck from* the AVR work if it wasn't branched but a
different head.

>  So we only have Holger saying mtn can't merge the dreambox branch, and
>  people ignoring what I said about the avr32 branch.
>
We would like to merge easily and branch cheaply. Obviously, mtn can
cope with the latter and lacks in the first. Is that alone enough to
move to hg or git?

I found this: http://utsl.gen.nz/talks/git-svn/intro.html, and I quote below:

What Mercurial (=Hg) has over git
=========================

Mercurial is missing lightweight branches that makes git so powerful,
and there is no content hashing, so it doesn't really do the whole
"revision protocol" thing like git. This is why people like Ted T'so
say "git has more legs".

However as a version control system in its own right, it's certainly
one of the best. And if you consider that it is almost a twin brother
of git, being written in response to Larry McVoy's Great Temper
Tantrum™ and its first release only a couple of weeks later than git's
first release, and given all that it has achieved, it's an outstanding
accomplishment.

Here are some of the reasons why.

Portability and Consistency

Mercurial, like Bazaar-NG, is written completely in Python (with some
performance critical parts in C). So, if you like Python you might
find that good. If you're on Windows it's probably a lot easier to get
going. Hey, maybe it will even one day run on IronPython on .NET.
Optimisation for the Cold Cache case

In the "cold cache" case, git typically needs to load a lot of blocks
to do some operations. Mercurial, on the other hand, gets away with
far fewer seeks for them. This means it can be a lot faster - for
instance, one use case that Mercurial is a lot faster is applying a
ton of patches.

In the "hot cache" case, git typically blows Mercurial out of the
water, except for operations where git is having to do searches to get
the data, like annotate.

Bundle efficiency

Mercurial's hg bundle does a really, really good job of making small
packs. With the e2fsprogs repository, it managed to make a pack that
was 50% smaller than the default git pack, and its default bundle was
20% smaller than an agressively (and expensively) packed git pack.


Regards,
-- 
Leon