
Torvalds: git vs CVS - helwr
http://marc.info/?l=git&m=113072612805233&w=2
======
ableal
Exercise: what are the downsides of the current generation of DVCS ?

(Assume you may be something other than a coder that carries all files in a
laptop.)

~~~
nuclear_eclipse
Poor or inefficient support for large binary assets, such as compiled objects,
images, or video. Especially in the context of video game development, binary
assets that constantly change are highly painful to deal with in Git or
Mercurial.

~~~
naner
How is it possible that nobody has dealt with this problem yet?

~~~
pmjordan
Active open source development rarely meets "AAA" game development.

~~~
sshumaker
One could argue that the traditional source control model (where everyone has
a copy on their own machine) isn't a great way to deal with huge binary
assets. I've worked on game projects where the binary churn was on the order
of gigabytes a day. Even though everyone was physically co-located, when
everyone arrived at 10am and started to update to head, a hundred computers
all trying to download the days worth of 2 gigs of assets over the network
didn't make for a pretty picture.

You can try to cronjob the updates, staggered around 4am. Or you can realize
that the majority of people are only modifying a subset of these assets, and
roll your own link-based asset manager for large binaries.

~~~
pmjordan
Yes, absolutely, you wouldn't want everyone to keep pulling _all_ data, git-
style. The programmers usually only need the assets in the game-ready format,
not the source models, textures, etc. which are typically much larger, and
only needed by the artists/level designers working with them.

------
AngryParsley
_But if you have hundreds of developers, and you have a dynamic trust network
(I trust some people, they trust others, and we all tend to trust people more
or less depending on what they work on), the CVS model is absolutely HORRID.
It just doesn't work._

I can count on one hand the number of projects described by that sentence. No
surprise, the Linux kernel is one of them. Linus built a tool to satisfy his
needs. But most developers work in smaller groups, and these groups have
explicit trust. Working at a company, the trust network isn't dynamic. Even in
large open source projects, most of the commits are by a handful of
individuals. It's not a big deal if the occasional one-time contributor
e-mails a patch.

But most of my gripes with git don't have to do with its ideas. Although it's
distributed revision control, in my experience everyone designates one repo as
authoritative. Like centralized RVCs, certain users are explicitly granted
write access to said authoritative repo. So git ends up working like an svn
repo with a ton of branches.

My complaints about git have to do with its interface. Coming from svn, git is
very frustrating to use. Certain benign commands in svn will erase your data
in git-land. For example, "git checkout filename" is the equivalent of "svn
revert filename"; it erases any uncommitted changes. Of course, git has a
revert command as well, but it doesn't behave like other RVCs. Git checkout
can bite you if you have a branch with the same name as a file or directory in
your source tree.

My biggest annoyance is if I accidentally commit and push something. Usually
it's when I forget which branch I've checked out. Undoing a commit/push means
rebasing or resetting, and that's where git drives me insane. I have used
subversion, CVS, and even Visual SourceSafe, but only in git have I lost
previous commits. Again with the misleading terminology. Why call them commits
if you can destroy them with a single command?

~~~
parbo
It sounds like you'd like Mercurial better. The interface is much more SVN-
like.

~~~
AngryParsley
I totally forgot about Mercurial, probably because I have no bad experiences
associated with it. I haven't used it much, but the times I have used it have
been forgetful. I think that's a good thing when it comes to revision control.

------
cschep
This is a super level headed response from Linus on a topic that he usually
rants about. That's pretty cool.

~~~
rabidgnat
I follow the Git mailing list, and he's even-keeled and surprisingly helpful
in discussions. The tone of the original post is representative of what he
normally writes.

I'm sure he's no saint, but his most famous rants were responses to sniping.
The Minix/Linux debate was started by Tanenbaum, Bram Cohen picked a fight
over merge strategies in a list discussion, and the 'C++ sucks' rant was in
response to some flamebait.

------
Auzy83
We just made a selection of version control system at
<http://getnightingale.org>, and Git isn't that great either (it's over-
hyped). CVS does suck (and SVN does too for our purposes). But Git requires
that users either use cygwin or install half a linux environment in Windows.
Just because Git is coded by Linus, doesn't instantly make it a good product.
In the case of Git, I REFUSE to force newbie windows developers who want to
mess around with our project to be forced to install 2 linuxy environments, or
have to integrate it into mozilla build (every other system is just a simple
file you can add to path).

We settled with Mercurial, because hgweb isn't that memory intensive and our
512MB RAM prgmr VPS can handle it (although, we hope to upgrade the VPS, to
allow more checkout's simultaneously). SVN/CVS also consume little ram on the
server too though.

People who wish to make a selection should try them all out, and ask around.
Because whilst Git users are very passionate about Git, I couldn't find a
single one on IRC who had recently tried mercurial or Bazaar. Furthermore very
few (if any) actively used Git in Windows

But that's just what I found. I didn't run proper benchmarks and things would
be different if we had a better server (Loggerhead for bazaar wanted 2gb when
running).

~~~
0x44

      But Git requires that users either use cygwin or install half a linux environment in Windows.
    

That was true, but is no longer. There is a Windows port of git called MSysGit
available on google code: <http://code.google.com/p/msysgit/> .

~~~
Auzy83
MsysGit is still a huge collection of random packages, many of which you don't
need for other revision control systems. No it isn't cygwin, but you require
130mb of linux packages still to install it.

It's nowhere near self contained. Bzr,Hg,cvs,svn (and others), are just a
small directory, and need none of those. MsysGit is overrated too. Usable yes,
but ideal? Hardly..

------
mgunes
This is effectively a summary of his Google Tech Talk on git.

<http://www.youtube.com/watch?v=4XpnKHJAok8>

------
clemesha
"So one of the worst downsides of CVS is _politics_. People, not technology."

~~~
Oxryly
Although it's not as if switching to distributed revision control will
eliminate politics. It just transforms them and pushes them around. Who owns
the mainline of a project? Why won't s/he accept my patches? etc.. etc...

~~~
thristian
Of course it doesn't eliminate politics, but it cleanly separates technical
concerns from political ones. With a centralised version control system,
technical problems can have political ramifications ("$LEADER said she'd give
me commit access three weeks ago and she still hasn't; sure she _claims_ she's
suffered a server crash but I think she just doesn't like me") and vice-versa
("$COMMITTER didn't like $OTHER_COMMITTER's contributions, so they started a
revert war").

------
ableal
I'll leave here a short note on a test I ran with mercurial v1.31, it may give
someone ideas. The document was a 45 slide OpenOffice presentation (.odp,
OO.org v3.1, Linux). Large font text, nearly all pages had one or more images.
Did not delete/replace pics more than a couple of times, but did reorder a
bit, especially at the end.

Surprisingly, reordering did not affect much the size of the hg store, which
is only 60% over doc size. That may be either because hg is being extremely
smart about the content, or because OO doesn't move binary chunks around after
they are inserted in the file (more likely).

On each commit, a script noted changeset number and output of 'ls -s' on the
doc file and the .hg/.../_file.d store. Only started at 11, and trimmed most
of the lines.

    
    
        c.set  file   file.d
        11     320     632
        15     488     944
        20     736    1336
        25    1056    1804
        26    2044    2800
        29    2336    3260
        30    2336    3480
        31    2356    3560
        35    2688    4104
        38    2852    4388
        39    2848    4468
        40    2856    4540
        41    2924    4676

------
nearestneighbor
I program solo, and for fine-grained version control, I use comments and
conditional compilation, which I remove when the time comes. I also take
periodic tarball snapshots of my code just in case.

Before you downmod me to -∞ for my uncouth approach, consider this:

According to Linus, Git > tarballs > CVS > SVN (he made a statement about
tarballs being better than CVS somewhere else). That leaves Git and tarballs.

Now, Visual Studio is my primary development environment, and it does not
integrate with Git (as far as I know), and Git just isn't well-supported on
Windows (there are some fragile solutions). Secondly, I probably spent a whole
day playing with Git where it's supposed to shine (OS X with GitX), and I just
find it kind of awkward and unintuitive for no benefit.

~~~
solutionyogi
I use Git on Windows with Visual Studio and I don't face any issues
whatsoever.

Yes, Git is not integrated with VS but I have no trouble switching to explorer
and commit my changes using TortoiseGit. TortoiseGit scans my working
directory and presents list of all the changes made in a session.

And yes, to be on safer side, I copy and store my working directory + Git to a
different location.

~~~
nearestneighbor
Check out these replies:

[http://stackoverflow.com/questions/1500400/is-tortoisegit-
re...](http://stackoverflow.com/questions/1500400/is-tortoisegit-ready-for-
prime-time-yet)

It's not just the fragility and lack of integration, but also I'm just not
seeing much of a benefit to counterbalance the complexity and awkwardness.

~~~
solutionyogi
Well, I have been using it for 'production' work for last 6 months and I have
not found any issues. I am not suggesting that everyone will have the same
experience but I think you should give it a try before dismissing it outright
based on someone else's experience.

Also, if you could provide some real details on the 'complexity and
awkwardness', I could share my experience which could be helpful.

~~~
nearestneighbor
> give it a try before dismissing it

Giving it a try can only prove the presence of fragility, not its absence :-)

Generally, people are very reluctant to criticize "hip" tools like e.g.
Clojure, Haskell, Google Go, Git or its accessories. So, when 3 out of 4
people say they had problems with it, to me it weighs very heavily on the
negative side.

~~~
wvenable
For the record, I agree with you on Git (on Windows at least). It's improved
at a rapid pace but it's still a bit awkward.

However, that's no reason to dismiss all version control.

~~~
nearestneighbor
I'm glad you agree, because for the rest of the equation (Tarballs > CVS >
SVN), Linus agrees with me. So you see, I embody the combined wisdom of both
of you, as far as version control goes.

~~~
wvenable
You have his equation wrong. He says in this article that SVN is still better
than CVS. And really, I would agree that tarballs are better than CVS. So the
equation is more likely SVN > Tarballs > CVS. Don't put words in Linus's
mouth.

Also Subversion no longer stores it's data in a database so Linus's objection
in this article has been resolved.

Finally, Linus's needs are pretty unique in the world. Linus isn't satisfied
with Subversion for the same reasons it might work perfectly well for you.

~~~
nearestneighbor
> He says in this article that SVN is still better than CVS.

He says SVN is better, but is more fragile (which for source control, I
interpret as being worse):

    
    
        SVN fixes (supposedly) those "implementation 
        suckiness" issues. ... 
        I think it's also a much more fragile setup and 
        there's apparently been people who lost their 
        entire database to corruption
    

Even if SVN = CVS, clearly Tarballs > SVN, according to him. His actual quote
was Tarballs >> CVS. I can dig it up if you can't.

~~~
wvenable
Thousands of companies (and millions of developers) use Subversion. It's 10
year old. It's an Apache project now. It's solid. It's a simple and easy to
use tool that will make your life better. That's all.

If you find that personally offensive, so be it.

~~~
koenigdavidmj
Linus was more ranting that Subversion uses a binary database. If it gets
corrupted, you're screwed.

CVS's database is just RCS files, plus a little. Nice and easy to restore if
Bad Things start to occur.

~~~
wvenable
Subversion now use text files for storage too. You have the option of that or
the Berkley DB.

------
eplanit
The longevity of CVS speaks for itself. It's not perfect, but it has served me
and my projects perfectly fine for over 20 years. Anytime I've ventured over
to work with some other VCS, it inevitably was a distraction and a waste of
time.

Any new VCS goes through these same rants -- not able to distinguish
themselves on merit, they simply attack the dominant player. With Git, one
learns quickly -- oh, it's all about the Python 'community' and their
politics, I see.

When it ain't broke, don't fix it!

~~~
prog
I once moved a project from ClearCase to CVS because the performance of our
ClearCase setup was _really_ eating into our time. I didn't have any major
complaints from SVN as well.

Some reasons I moved to bzr are: \- repository backups are free due to the
distributed nature \- python scripting \- fast local operations

So, yes, I don't really have a big issue with svn (or cvs) but given a choice
I would go with bzr (or any other DVCS).

