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

[Richard Purdie]

On Tue, 2008-03-11 at 15:03 +0200, Paul Sokolovsky wrote:
> On Tue, 11 Mar 2008 12:39:13 +0000 Richard Purdie <rpurdie at rpsys.net> wrote:
> > You will never have seen me argue git has a nice UI. I've said quite
> > the opposite on many occasions. I have said its powerful but thats
> > different.
> 
> It's nice to have that said explicit - different. Supposedly it's more
> powerful for developers, but how good it is for end users? How many
> industry entities select git as their in-house SCM? I doubt that too
> many, knowing too well that many still select just CVS.

OE is there to serve a multitude of people, both developers and end
users. For the end user, hopefully we can document the basics of "git
clone", "git pull" and "git diff" or documentation already exists for
this. 

Also, I think more end users coming fresh to OE will know how to do this
with git in the current climate than with monotone, hg or any other
distributed SCM.

Regarding industrial entities, hopefully we call agree CVS is a pretty
bad SCM and that proves said industrial entities don't know what they're
doing, usually since it often it comes down to politics rather than
technical merit. I know of a few surprising companies using git FWIW
although I know of a few abominations in use too.
 
> > I'm assuming we're considering distributed scms but you know this ;-)
> 
> Yes, I'm trying to hint that arguments like having something already
> installed, or some niche, but big project already using it, are not
> necessarily valid for the topic of selecting SCM for OE.

You're asking about end users and how we should represent them above
then you claim its irrelevant?

I'm not saying this is the only factor to consider but I am arguing that
its a valid factor to consider.

> I'd really like someone who lead this idea to actually try few
> "advanced" usecases with both git and hg. But if that's not going to
> happen, at least let's not pretend that git is going to be "better"
> than hg or even mtn. It will be just different, possibly, bringing more
> issues overall.

Well, we have use cases explained where mtn has failed and we know git
is better. Some of us use git for other projects like kernel work and in
my/their opinion, we *know* it can do some things better.

Personally my hg knowledge is weak. If thats the case for me, it
probably is for a lot of other people and I think its valid to use that
as a factor. I'm not against learning hg if it solves all our problems,
I just don't think it will.

So, firstly, is anyone else willing to propose any other distributed
SCMs or is this just a choice between hg and git? If so, we have three
options:

1. Continue as we are with monotone
2. Switch to git
3. Switch to hg

We've talked about whether 1 is a good idea or not and assuming its not,
what are the pros/cons of 2/3?

git
---

* Most likely to to be installed on a given newcommer's machine
* Most likely to have been used before by a newcommer
* Has lots of documentation
* Has a lot of users
* Powerful web and visualisation tools
* Very actively growing
[I've not listed the other git features since I don't know how they
compare to hg, help?]

hg
--

* Has a nicer commandline?


These are just the issues I can know for near enough certain. Could one
of the hg proponents please put together a list of what makes its great,
and compare its branching/merge handling features with git?

Another thing we should consider is whether something is likely to
improve over time. This is something we hoped would happen with monotone
and whilst it has to an extent, it hasn't as much as we'd have liked.
Personally I think someone will write a nice frontend (porcelain) for
git eventually but we don't have a guarantee of that. The strength of
the communities in question plays a part here.

Cheers,

Richard