[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Revision control
Re: Revision control
Wed, 11 Jun 2008 10:46:16 +0200
Am Dienstag 10 Juni 2008 22:11:20 schrieb address@hidden:
> It doesn't seem to detain any of the Linux contributors, nor the Xorg
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
> > 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
- 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
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
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
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
> > 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
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
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
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
- 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.
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):
Description: This is a digitally signed message part.
- Re: Revision control, Arne Babenhauserheide, 2008/06/01
- Re: Revision control, olafBuddenhagen, 2008/06/03
- Re: Revision control, Anatoly A. Kazantsev, 2008/06/03
- Re: Revision control, Arne Babenhauserheide, 2008/06/03
- Re: Revision control, Arne Babenhauserheide, 2008/06/03
- Re: Revision control, olafBuddenhagen, 2008/06/07
- Re: Revision control, Arne Babenhauserheide, 2008/06/08
- Re: Revision control, olafBuddenhagen, 2008/06/10
- Re: Revision control,
Arne Babenhauserheide <=
- Re: Revision control, olafBuddenhagen, 2008/06/17
- Re: Revision control, Arne Babenhauserheide, 2008/06/23
- Re: Revision control, olafBuddenhagen, 2008/06/26
- Re: Revision control, Arne Babenhauserheide, 2008/06/26
- Re: Revision control, olafBuddenhagen, 2008/06/28
- Re: Revision control, Arne Babenhauserheide, 2008/06/28
- Re: Revision control, olafBuddenhagen, 2008/06/29
- Re: Revision control, Arne Babenhauserheide, 2008/06/30
- Re: Revision control, Michael Banck, 2008/06/17
- Re: Revision control, olafBuddenhagen, 2008/06/18