[oe] monotone/git (was hello...)
Michael Krelin
hacker at klever.net
Thu Oct 4 13:51:10 UTC 2007
> this will be my only to this topic but I see that as following:
Why won't you clarify your points?
> git:
> cons:
> - Incompats with other versions
What do you mean?
> - repacking (even if probably all known races are fixed)
That's not a contra if we compare with monotone.
> - shell mess with bashism and GNUism
Very true and, likely to be a show-stopper, anyway.
> - still complicated to use
Well, if you use the monotone subset of git, it's not ;-)
> - Does not track directories
Is it a problem with OE?
> mtn:
> cons:
> - Speed on rev pulling (I think mtn ls and status, diff is quite fast)
> - we can not easily merge the dreambox branch (this is why I wrote
> mtn2git)
Aha, now I know the script exists :-)
> pros:
> + trust (I don't feel like remembering the latest over night)
Can you elaborate on the expression in parentheses?
> + awesome manual
I wouldn't call it awesome when it goes beyond trivialities, but I don't
think it's a problem with either SCM.
> + trusting the code base (git is catching up, Linus is a god...
> but...)
Well, OE relies on git codebase indirectly anyway ;-)
> + certs attachable to revs
> + attributes and other testresults are attachable to files and it
> is on my todolist to use them
> + tracks directories
> + portable
>
>
> The last three/four reasons are the one why I would propose to stay
> with mtn as the main repository. I'm also working on a git2mtn script
> (after having merged the dreambox branch) which could make git a
> (semi) supported system for OE (if someone will host it).
The bottom line is - we're not going to move anytime soon. And I agree
it makes sense. I'm yet to see what are these attributes and other
testresults attachable to files (sounds interesting), but I'm a bit
afraid of your idea of (ab)using it, since that may make us get stuck
with mtn in the future no matter what.
Love,
H
More information about the Openembedded-devel
mailing list