Re: monotone/git (was hello...)

[Michael Krelin <hacker@klever.net>]

> 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