Hi Oded! Trimming your message.
On Sunday 18 Oct 2009 08:51:23 Ohad Lutzky wrote: > In the case that this is only a 20 minute lecture, I wholeheartedly agree. > I do think that git should be mentioned, in a one-liner, as "a more > advanced tool that also allows you to work offline". > Naturally, you should mention it for completeness sake. You should also mention bzr and Mercurial and/or refer people to http://better-scm.berlios.de/ or something similar [better-scm] for further reading, a comparison and discussion. Here is what I think of the various prominent FOSS VCSes : * Subversion (svn) - naturally, I may be biased towards it because I'm still using it for a lot (probably most) stuff, and have also contributed to it, a long time before git or hg existed (or even Bazaar and Bazaar NG which is now bzr), when its main competitors were Arch/larch/tla and Aegis and later darcs. See also: http://onlamp.com/pub/a/onlamp/2004/01/29/scm_overview.html ( Monotone is still around and served as the main inspiration for git, but from my impression very few people use it. ) Subversion is very polished - it compiles and runs well on most (all?) modern UNIXes and many old ones, works very well on MS Windows (as a client and as a server), has an intuitive syntax and command output and mostly works as expected. Branching and merging there is much nicer than with CVS, at least in my opinion, though branches and tags are just free form directory copies - not "real" repository-wide tags and branches which git and hg support. I can probably rant a lot about the unjustifiably poor perception of Subversion in the blogosphere that I read, where people often do a apples-to- oranges comparison of it to something else. I have learnt git and hg and am still more than willing to use Subversion for some stuff due to its usability, portability and software engineering (having APIs, etc.) advantages, which I have called its "polish". In any case, as Ben Collins-Sussman notes, while Subversion has proven popular in the open-source world to a large extent (though lately there was a trend to use VCSes such as hg, bzr, git, etc. instead), it has been extremely popular among the "80%" of software developers: various developers who are not working on shrinkwrap software (or alternatively shrinkwrap software that is niche but still profitable enough to make a living out of), and that are using it as a high-quality, cheap (gratis in fact) and open-source alternative to Microsoft Visual SourceSafe, CVS, Perforce, ClearCase, etc.: http://blog.red-bean.com/sussman/?p=79 I know at least two people in Israel who give Subversion consulting, and often it just means they get a monthly or yearly consulting fee to agree to support Subversion in case there's a problem with it, which usually does not happen because it works very well, but is needed to settle the pointy-haired bosses (PHBs) who need commercial support. This is still probably cheaper for them than paying for a ClearCase licence, and naturally Visual SourceSafe, despite an innocent and easy appearance, is much more hazardous and time consuming in the long run (and obviously is not portable at all). OK. enough about svn. * bzr - my main problem with it is that it is painfully slow. Many local bzr operations are slower than even the equivalent svn operations which finish pretty quickly here. While it may be another SNAFU on my relatively-old-and- constantly-updated Mandriva Cooker system, which works pretty well and is fast, but sometimes acquires some weird problems, http://dazjorz.com/ have said that a local filesystem bzr was slower for him than svn in conjuction with Sourceforge, and he is using Debian I think. Part of the problem seems to be that bzr is written in pure-Python, while hg which is also mostly Pythonic has parts written in ANSI C for speed. In any case, this horrible performance makes bzr a non-starter for me. As patient as I can become, it is still too slow to be effective. Now the GNU project wants to convert the Emacs CVS repository (with a large codebase and years upon years of history) to bzr (which is not in the process of becoming a GNU project - possibly a typical GNU NIH), so hopefully this will motivate some work on optimising bzr and making it scale better. * git - I've been using git in conjunction with github for a long time now. github is a very nice service (though I'm skeptical about its profitability), but git still leaves a lot to be desired. I still could not fully get to the bottom of the program model of git, and a lot of git usability and tricks stuff has been the topic of a lot of blog posts lately. I don't recall so many blog posts about Subversion when it started to become popular. There are several possible explanations for this, but I tend to think part of the problem is that git has a more complex and counter-intuitive architecture[intuitive] and provides more fodder for blogging than svn which is easy, simple and easy-to-understand. git often throws me off and gives me a weird error which I cannot tell how to avoid or workaround . The Freenode #git people tend to be very helpful about that (they never tell me to "RTFM" - :-)), but I still find it frustrating that I cannot figure out something so mundane on my own. ("Why does git do it to me?"). git also lacks a good API that svn, bzr and hg have, and seems to be a mish- mash of stand alone programs (with a monlithic library - ?) - some of which are written in shell or Bash - that emit inconsistent output, which is mostly human readable (though is often too verbose, IMO), but I'm not sure if it's as easy to parse as that of the Subversion svn client, to say nothing of using the svn ANSI C APIs or Perl/Python/Ruby/Java/etc. bindings. Another aspect I dislike about git is not technical but social: its hype. git converts tend to be arrogant, snobbish, boastful (about git at least) and blog about it indefinitely to everyone's displeasure. It's possible that they are a minority, but they are a loud and vocal minority and I dislike it. I don't think believe in a conspiracy theory that there's a single corporate entity hyping git as was the case for Sun and Java at the time, but even grassroots hype tends to be a big red flag for me. Looking back, I can recall many technologies that were not hyped at all, whether by the community or by a company, and yet proved to be very popular: HTML, C, Perl, Unix. They tend to have gotten established by the time most people have heard about them. None of them are perfect, but many hackers are still fond of them. There were many fine technologies that were hyped or even still are, but I keep feeling that those who hype them tend to hide something, and are not completely honest about their limitations, which may often make them a non-starter even for hard-core hackers. I have learnt git and it's not too bad, though as Shachar indicated may be very dangerous and destructive for allowing you to lose history (at least from what I understand). However, I still find the hype suspicious and a vice to git. * Mercurial / hg - I've recently played with Mercurial, and even worked on a few projects using it. I found it easier to use than git, a bit less counter- intuitive than Subversion (there are usually useful workarounds) and pretty nifty overall. I did run into a case where it didn't do the right thing after having several clones of a remote repository which caused the Directed Acyclic Graph not to merge gracefully. It's reversible, I think, but still threw me off due to my expectations with the non-DAG-based Subversion. Nevertheless, hg seems to combine some of the best advantages of git and svn, while having relatively few disadvantages of its own. ---------------------------- There are many other FOSS players in the version control system, and naturally there are many low-quality and high-quality proprietary alternatives, but these seem to be the most popular 3rd generation version control systems (after RCS and CVS). Regards, Shlomi Fish Footnotes: ---------- [better-scm] Caveat: better-scm is a site I originated and still am the primary maintainer - there may be similar sites elsewhere, and naturally, one can contribute to it by sending me patches. [intuitive] You are probably familiar with the old quote on one of the Linux newsgroups that "The only intuitive interface is a nipple. Everything since then is learned." This quote, while amusing and while it has a grain of truth to it, is not true. First of all, intuition (as opposed to say "instinct" or "inborn tendency") is something that we acquire as we go along. Reportedly, the differences that were discovered in the brain's biology between males and females, may be in a large part due to different treatment and baby care from the parents and from other people. (On the other hand, according to Feeling Good, one's favourite flavour of Ice Cream is believed to be mostly influenced by genetics.) What I'm trying to say is that we come to use a certain program (or even a library or API) with certain kinds of previous expectations brought on by years of previous experience with the real world or with computers. Some programs are very easy to use straight away. Some require a substantial amount of training and research, even if you're a geek. I'm not claiming the latter approach is necessarily worse, but we all agree that building an intuitive interface that is easy to get accustomed to has its merits. I recall that back when I was looking for a better job as a programmer and went to visit my future boss who told me about the wonderful productivity of Perl and showed me a small program he was working on (without syntax highlighting, though), and despite the fact that I had already known C and BASIC, I could not make a lot of sense of it. Later on, after I studied Perl, I found it a joy to use and a good productivity boost, because it combined the advantages of both BASIC/QBasic/etc. and C (while still being somewhat slow and memory hungry, though, but this is usually not a large concern for me.). On the other hand, a Teluxer once told me that he did not understand what the Python-ILers have to discuss because Python was trivial. (He had done a lot of Perl). He told us that he once looked at a Python program and while knowing very little about Python, was able to hack on it right away. However, while I can be productive in Python, I still often miss many of Perl's advanced features, which are completely non-existent in Python due to design choices and "There's one good way of doing it"-ism. This is similar to the fact that I sometimes write funky code in Perl to work around the lack of Lisp's macros. So Python is more intuitive than Perl, but it comes at the cost of smaller expressiveness. (I don't want to start another Python vs. Perl holy war - let's not go there.). -- ----------------------------------------------------------------- Shlomi Fish http://www.shlomifish.org/ Optimising Code for Speed - http://shlom.in/optimise Chuck Norris read the entire English Wikipedia in 24 hours. Twice. _______________________________________________ Haifux mailing list Haifux@haifux.org http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux