Re: "Offline files" and Linux

On 10 Jul 2007, Tim Southerwood outgrape:
[Linus's git talk]
I found his performance disappointing. Great man he is, but arrogance is
never becoming, even when played out as humour.

I don't think Linus was being especially arrongant in that talk. If you
don't know git, you might think that his comments regarding how it
knocks the socks off basically everything else were arrogant hyperbole:
but the thing is, those comments are *true*.

Subversion is left in the *dust* by git (and probably by bzr-ng and
other of the new breed of distributed VCSes, but I only really know git
of that group). I can't think of anything subversion does that git
doesn't do better, with the singular exception of acting like CVS. The
problem there is that most of what CVS does is totally broken by design
anyway, and anything emulating it will necessarily replicate a lot of
that brokenness: but if people are unwilling to retrain you might have
no choice.

(subversion also used to have much better docs and work on Windows.
Git has fixed the second; the first is improving fast but isn't quite
there yet.)

One trivial example of a useful thing git can do which is utterly
impossible in both Subversion and CVS: `git-blame' (the equivalent of
`cvs annotate' or `svn blame') with the -M option doesn't just tell you
what version each line was last changed in: it tells you *where those
lines came from* if they were moved from other files. This single
feature alone would be enough to make me migrate from other VCSes in an
instant, but there are similarly immense improvements in virtually every
other part of git, before you even get to the distributed-VCS part
(which Linus obviously thinks is central: given his focus, he would :) )

I did agree with his points in the context of the kernel; subversion would
be next to useless for that type of distributed development, but it is
excellent for centralised projects - however, it would have been gracious
to say something to that effect and then leave it alone.

The point here is simply this: why is any project `centralized'?
Ignoring things like single-company single-workplace development with
very limited disk space (in which case you can easily set $GIT_DIR and
ignore the distributed-development stuff) I can't see *any* circumstance
in which it makes sense to explicitly select a version control system
on the basis that it can't handle distribution. Why select a version
control system on the basis of features that it *lacks*?

Picking Subversion because its command-line interface and workflow is
similar to CVS's, *that's* understandable: git is quite different to use
and writing a porcelain that makes it work the same is incredibly
difficult. (The problem is, when someone else does something git can do
which CVS can't, how do you show this to the user? Branch merging, for
instance, is incessant in git, but CVS can't do it at all, and I've
encountered users who are confused at the very idea because CVS can't do
it...)

But I'd say `my users are CVS geeks who won't retrain' is the only real
reason to use Subversion anymore. I still have it on the system, but
just about the only thing that runs it is git-svn: I track remote
Subversion projects in git...

Pity - I lost some respect for him after that...

Losing respect for people because they tell the unvarnished truth is
silly. Subversion was a worthy effort but it made the mistake of being
the first major free attempt at implementing something better than CVS,
so its authors were, um, stuck in a bit of a mental box. More recent
versoin control systems have broken well and truly out of that box,
but Subversion is still stuck in it.

Personally, I find using Subversion, let alone CVS, like being stuck in
jail. (At work we're using SCCS. *vomit* forget rename tracking, this
thing doesn't even know what directories are...)

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously
.

Relevant Pages

  • Re: Controlling project version
    ... over CVS. ... I've used CVS and Subversion quite a lot for a number of years. ... The branching in Subversion is a gazillion times better than CVS if you ... started playing with Git. ...
    (php.general)
  • Re: "Offline files" and Linux
    ... I didn't say git wasn't good. ... subversion, which is by your argument, a limited model, is perfectly good ... svn certainly isn't rubbish: it's just that the authors approached ... it from a perspective of `fix the uglinesses in CVS'. ...
    (uk.comp.os.linux)
  • Re: Why SVN?
    ... Is it because SVN is more like CVS than the other choices? ... Subversion is reasonably familiar to those who are used to the CVS paradigm ... however Git was written to achieve nothing more than managing the ... wish there was better handling in distributed revision control ...
    (comp.lang.ruby)
  • Re: suggest a version control program
    ... tags and branches. ... While the command is "svn copy", ... While I prefer CVS in most cases because, if necessary, one can edit the ... I have some experience with git because I use ...
    (comp.unix.programmer)
  • Re: Version Control Software
    ... including the old warhorse CVS. ... migrate to a different platform (server or PC), ... git may work, http://git.or.cz/, ... subversion may work better, http://subversion.tigris.org/, ...
    (comp.sys.hp.mpe)