Re: Revision control

[Arne Babenhauserheide]

Am Dienstag 10 Juni 2008 22:11:20 schrieb olafBuddenhagen@gmx.net:
> It doesn't seem to detain any of the Linux contributors, nor the Xorg
> ones...

Not anymore, since they became used to it. 

One example: Up until 4 years ago, I was a Mac User who seldomly touched the 
console, but I don't grunt about having to use the console anymore, because I 
learned its ways. 
It's the same with not perfectly intuitive interfaces and similar. 

Still I remember why I wanted to have a GUI to things, and why I wanted 
Interfaces to be in such a way, that I instantly get a feeling of how to use 
them. 


> > 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. 

That isn't my experience. 

The key to having a powerful but easy to use tool is usability. 

- Have an intuitive set of basic commands. 
- Have sensible defaults, so most people don't have to change anything to use 
your tool. 
- Make the commands most people use quickly accessible (like "hg up" instead 
of "git checkout -f" to update all files). 
- Test your usability. 


> 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.

No. It just proves that people can get used to any kind of workflow, however 
inefficient. 

I remember my grumbling, when things changed from the way I was used to do 
them to a simpler way, because suddenly what I had learned was useless (and I 
had to relearn, even though that relearning was easier than the initial 
learning). 

People cling to their habits, so if you get them to learn your ways once, the 
chances are good that they will grumble at first but keep and even defend 
them. 
At least as long as no new big obstacles arrive which force them to rethink 
their ways (for example losing all project history or other horrible things 
like that). 


> > 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.

Do I have to know what exactly the init system does internally. 

I don't know the definition of the exact runlevels (anymore). 
It's enough for me to know, that 
$ rc-upate add blah default
makes blah run when my system starts at the proper time. 

I do know about scripts, now. But I didn't know in the start. Gentoo provided 
them for me. I learned about them, when I felt the need to do so. 

I don't know what Signals do internally. I just know I can control things with 
them (like killing a process). 


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

I use KDE, which allows me to change whatever I want, but doesn't force me to 
change it, because most defaults are sensible. 

I also use it on a Gentoo box, where I had to define most things myself. But I 
didn't have to know about the guts of my system, just about the things which 
I can (and should) adapt to my needs. 

Forcing users to learn things which aren't strictly necessary for using a tool 
just steals their time. 


> > 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?), 

It's two days younger than git, as far as I know :) 


> and still seems to miss features that I consider crucial.  That's hardly the 
same level... 

Uh, what about proper crossplatform support like compiling on my Hurd? 

Mercurial had that from the beginning, while Git struggles Linux bound. 


> > 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...)

40% of the sourcefiles? 

I don't write huge programs, but I I normaly have many places in a program, 
which are simply stable, so I don't touch them again for a long time. 


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

It's related to the question which revision system will have better 
performance, since the repository format works differently. 

For pulling changes, Mercurial only touches the changed files inside the 
repository. If only a subset of the files changes, this access is superior 
(in terms of disk usage) to having all files in one pack or having to touch 
every changeset. 

If a big percentage of the files gets changed, this advantage fades away, as 
the number of disk accesses becomes about the same. 


Still, for me the question of the revision control system is more a matter 
of "Which system will offer Hurd developers most useful features, while 
getting into their way as little as possible." 


- CVS massively gets in your way, but its syntax is what people are used to. 

- SVN gets in your way far less, and it is quite similar to what people are 
used to. It still limits what you can do by not having local commits out of 
the box and similar. 

- Git offers some things only few workflows need and offers you flexibility, 
but gets in your way with necessary garbage collection (for active projects), 
and its syntax and use are confusing at times and almost always badly 
documented. 

- Mercurial doesn't have every power-feature of Git (using some workflows 
requires more work than with git) but it offers you flexibility and doesn't 
get in your way, and its syntax is mostly what people are used to while also 
being very well documented. 


That's the reasoning I used when I decided which version control system to 
use, and I think it is valid for most projects. 


Best wishes, 
Arne
-- 
Unpolitisch sein
Heißt politisch sein
Ohne es zu merken. 
- Arne Babenhauserheide ( http://draketo.de )

-- Weblog: http://blog.draketo.de
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software. 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln

-- Mein öffentlicher Schlüssel (PGP/GnuPG): 
http://draketo.de/inhalt/ich/pubkey.txt

signature.asc
Description: This is a digitally signed message part.