Am Dienstag 10 Juni 2008 22:11:20 schrieb [EMAIL PROTECTED]: > 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.
