Re: Revision control

[olafBuddenhagen]

Hi,

On Sun, Jun 08, 2008 at 09:29:00AM +0200, Arne Babenhauserheide wrote:
> Am Samstag 07 Juni 2008 17:47:28 schrieb olafBuddenhagen@gmx.net:

> If git isn't readily usable for me, then it is quite probable, that it
> is unusable for many programmers, including some who might be
> interested in contributing to the Hurd. 

It doesn't seem to detain any of the Linux contributors, nor the Xorg
ones...

In the latter case, I know that there was some grunting in the beginnig,
but it soon died out; git problems are hardly ever mentioned now.

(And again, I think most of them were only because some people didn't
bother to read up on the fundamentals in the first place.)

> Why do I _have to_ understand its basic concepts to use it without
> running into problems (as opposed to wanting to understand them,
> because they interest me)? 

No powerful tool can be properly used without understanding it. Unless
perhaps you put a restrictive interface on top of it. And in fact, the
git developers never cease to point out that such interfaces can be
easily created for git. The fact that very little actually exists in
this way, only proves that in spite of any initial grunting, people are
quite fine using the less shiny but fully powerful standard interface in
the end.

> UNIX usability is great. I didn't understand most of its basic
> concepts until I learned them in my informatics class at university,
> but I could use it quite well, because current tools provide a system
> which (mostly) just works. 

Without knowing about the file system, about pipes, about processes,
about signals, about scripts, about the init system? I have a hard time
believing this.

Unless perhaps you mean using GNOME. That is not what I was talking
about.

> But I think going for the simpler tool is useful, if the more complex
> tool doesn't offer significant advantages for the project. 

Well, I still believe git *does* offer significant advantages, for any
project. But again, I'm not really qualified to argue this point...

> And in my eyes the potential of Mercurial and git is about the same.
> What mostly differs is the order in which their features were (and, I
> assume, will be) implemented. 

Well, for all I know, git got almost all of its features within the
first few months. Mercurial on the other hand has been in the works for
several years by now (isn't it actually older than git?), and still
seems to miss features that I consider crucial. That's hardly the same
level... Unless by "potential", you mean "we should use it now, as it
might catch up some day" -- I hope you will understand that I'm not
convinced by that :-)

> For Linux development, where (as I now know) 40% of the sourcefiles
> are changed from one version to the next, and where most people who
> dare touch the code are longterm kernel hackers, git is the better
> choice, I think.  

Linux has fast changing parts as well as relatively stable ones. I don't
see why this would be any different with the Hurd. (Making corrections
for overall activity, of course...)

And anyways, I don't see how this is related to the choice of revision
control system.

-antrik-