[Haifux] [W2L] Call for lecturer + "Linux guru"

[Shlomi Fish]

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.