
Why is Git better than Subversion? - d99kris
http://stackoverflow.com/questions/871/why-is-git-better-than-subversion
======
badman_ting
Judgment is not the end of the world, and it is not a reflection upon one's
character to say that something is better than the tool one currently uses. In
other words, it's alright to say that git is better than SVN. If it weren't we
wouldn't have all stopped using SVN.

~~~
skore
In Linus Torvalds' talk on git at google[0], he mentions that the reason why
he did not choose SVN (one of the reasons why he saw no other way but to build
GIT) was that SVNs mission statement read "To create a compelling replacement
for CVS"... which Linus hated with a passion and thus could not see why he
would even use "a compelling replacement" of.

Interestingly enough, in the 'Open Source projects and poisonous people'
talk[1] with two SVN developers, they mention how they chose that line
specifically to make sure that everybody is on the same page with the scope of
the project - improving upon what people knew and were used to instead of
wild, new things. Specifically because they would often have people come into
the community with some grand plans that would have just exploded the scope.

It is of course arguable to what extent there could be a general rule to this,
but in this case, GIT is just so fundamentally and obviously the better option
than SVN. Had somebody tried to make SVN into GIT, it would have simply killed
SVN, so it was the right course of action to make it a new project. SVN was
destined to die by its design.

To see the GIT adoption rates these days (particularly due to tools like
GitHub) is very encouraging to people who like to think that sometimes,
starting over fresh is the only option. Of course, the thing you want to build
really has to be that much better than the old thing you're trying to replace.

So I agree with you - it's alright to say that GIT is better than SVN. The
crucial point to me, though, is that it is _so much_ better. So much better
that it is worth the effor to build and worth the effort of the community to
switch.

[0]
[https://www.youtube.com/watch?v=4XpnKHJAok8](https://www.youtube.com/watch?v=4XpnKHJAok8)
[1]
[https://www.youtube.com/watch?v=-F-3E8pyjFo](https://www.youtube.com/watch?v=-F-3E8pyjFo)

~~~
isxek
_In Linus Torvalds ' talk on git at google[0], he mentions that the reason why
he did not choose SVN (one of the reasons why he saw no other way but to build
GIT) was that SVNs mission statement read "To create a compelling replacement
for CVS"... which Linus hated with a passion and thus could not see why he
would even use "a compelling replacement" of._

Having experienced the workflow they learned from using another DVCS
(Bitkeeper) probably also influenced his decision at the time.

------
jmnicolas
Before even clicking the SO link, I knew this question was closed as off-topic
...

How about they make a dedicated space in SO where this kind of questions are
allowed.

I don't mean a free for all, but a heavily moderated part where you can ask
recommendations from your peers about the best framework / book etc as long as
it's related to programming.

~~~
viraptor
It's been there for ages:
[http://programmers.stackexchange.com/](http://programmers.stackexchange.com/)

Edit: Although it would be great if SO suggested moving discussions there,
instead of just closing as off-topic. You can close-move questions that belong
to superuser.com for example.

~~~
jmnicolas
Are you sure ?

Here's what they say :

Don't ask about...

1) general workplace issues, office politics, etc.

2) implementation issues or programming tools

3) Anything not directly related to software development

4) Questions that are primarily opinion-based

5) Questions with too many possible answers or that would require an extremely
long answer

I need 2, 4 and 5 to be able to ask "what's the best web stack for [my use
case]" ...

~~~
viraptor
Well, around half of the questions on programmers.se break at least 2,4,5
without any issues. Like "How to manage accidental complexity in software
projects", "Why would I use Angular?", "Would Python be too slow for client-
side use in Browsers?", etc. I've never seen a similar question closed on
programmers.se, even they don't respect all of those points.

------
GoldenMonkey
Choose the right tool for the job.

Git is the right tool for: branching and merging. And for cherry picking bug
fixes from disparate branches.

The git workflow revolves around creating a branch for a feature or bug fix.
Because in Git, branching and merging is cheap.

I've switched from a decade of using SVN, to Git and it is more than a shiny
new tool. It is the right kind of tool for the above.

In SVN, branching and merging is expensive, and if the changes between
branches were extensive enough.. the merge process would take a good weekend
of manual effort. In some scenarios almost impossible to do. And in some shops
I worked at, a branch with 3 months of differences would take a week to merge.
SVN is not the right tool for this.

~~~
T-hawk
By contrast, my job is a much better usage case for SVN. We have only three
developers, a single trunk, and rolling production deployments. We're never
concerned about release or feature branches or back-porting fixes. SVN is the
right tool for this. Git's extra abstraction layer around decentralization and
distribution would just get in the way. I have used git in a previous job and
for personal projects to get something up on Github, and I haven't yet missed
it here in our SVN shop.

Git is like applying an N log N solution to an algorithmic problem. Great for
something that in the naive case would be N² (N branches exchanging updates
with each of N branches), but when the problem space is very small, whatever
layer represents the log N is just overhead.

~~~
FeloniousHam
Even as a single developer, I find the effortless branching in git a killer
feature. Even with the poor (from a human perspective) implementation of EGit
in Eclipse, the ability to experiment in branches while preserving a "last
known good" point would be hard to give up.

Add to this the effortless sharing and "cost-less" review provided make git a
clear winner.

------
yoha
> This looks good at first, but just keep in mind the added complexity to this
> approach.

I think this is not exactly right. The approach is fundamentally different but
not more complicated. I think that the one important concept of Git is that
everyone has a complete copy repository, making the communication with a
server (through SSH, HTTP or the Git protocol) just an additional feature: the
very core of Git does not depend on anything.

~~~
einhverfr
It is more complicated, and the complexity buys you (assuming you need it) an
ability to relax certain limits of more traditional SCM solutions.

To be honest I don't find git to be better than svn for a lot of work, having
worked with both. There are fundamentally different decisions made, such as:

1 it is a lot easier to forget to add a file in svn, but it is a lot easier to
accidentally include a file you don't want in git.

2 workflow in svn is a lot more streamlined because you aren't dealing with a
multi-stage synchronization between your repositories (I am assuming the
reason you use version control is in part to collaborate).

Now, one thing I have started to get really into has been the combination of
github and svn, which gives you a lot of the benefits of svn and git together.
Now, it doesn't give you every benefit of git but it gives you enough of them
to make things easier all around in many cases.

~~~
chris_wot
I really don't understand why you believe it's more complicated. Why do you
say that?

~~~
einhverfr
ok:

Workflow with svn:

1\. Edit some files.

2\. svn commit -m "commit message" (ok, I add an svn up && before, but I
consider that one step).

done

Workflow with git:

1\. Edit some files

2\. git commit

3\. Review the message to see which files I actually want to add, if there is
anything that needs to go into git ignore, etc.

4\. Edit .gitignore as necessary

5\. git add *

6\. git commit -m "commit message"

7\. git push

So for simple cases you have 3 times as many steps, for more complex cases you
have more steps. Note that I usually push/pull from my own github repo and not
a central one because that avoids a lot of other hassle (and then use pull
requests for managing inter-repo changes, something github has done a nice job
with).

Additionally absent this you have a significant likelihood that you end up
with various files that aren't a part of your build environment (generated
makefiles, backups of generated makefiles, built packages, etc) accidently
pushed out to your central repo.

~~~
adekok
Only if you make git that complicated. Steps 2-6 can be replaced with:

git commit -m "commit message" file1 file2 ...

When you use a tool inefficiently, don't blame the tool.

~~~
einhverfr
That's still a lot more verbose than svn and even if you do that, you still
have only managed to reduce the number of commands required from 3x to 2x what
svn requires.

Also wouldn't you agree that git has a much steeper learning curve than svn?
What is this due to if not the added complexity?

~~~
janvidar
1) Edit some files 2) git commit -a -m "blah blah" 3) git push

So, it adds one extra command to push things to an upstream git repository.
But, this is the nature of being decentralized.

------
DougN7
Serious question: How/where do you check in your binary builds and debug
symbols if you use git? I've read it's not great at some not-so-large project
size. I'm using SVN on a micro-sized team with binaries from all released
builds safely checked in (which means the repository is probably 100GB-ish in
size), and it works great. [and to head off the argument - rebuilding from
source is not an option when you have to diagnose a customer crash when they
are using a 3 year old build of the software - you'd have to archive a build
machine to even have a chance...]

~~~
fournm
Why are your binary builds living in version control?

~~~
DougN7
Why wouldn't they? Conveniently and safely in the same location as the code
they were built with. Tagged the same way. Having a separate repository is
just inviting trouble down the road, no?

~~~
fournm
Because they're binary files, used entirely for archival purposes. They
shouldn't be changing, they shouldn't have "versions" that are anything to
deal with meaningfully as far as your repository is concerned.

They should be in flat storage somewhere, with some directory or file name
scheme that makes sense based on your version numbers / builds / what have
you. Backed up, (ideally) with hashes that verify that they're the same file
they once were.

------
wila
The question is about two -now old- versions of version control software
systems, the question was asked five years ago.

Both systems have matured quite a bit making the comments less accurate to
actually base an opinion upon.

------
grexi
For all Git users which hate SVN branching - I've added this small shell
extension last year:
[https://github.com/grexi/snippets/tree/master/svnaliases](https://github.com/grexi/snippets/tree/master/svnaliases)

------
chris_wot
Wow, the first answer is so... clueless!

 _Git seems to be the "new, shiny, cool" thing._

...

 _As said above: Git adds complexity. Two modes of creating repositories,
checkout vs. clone, commit vs. push... You have to know which commands work
locally and which work with "the server" (I'm assuming most people still like
a central "master-repository")._

...

 _Git has the advantage that it 's MUCH better suited if some developers are
not always connected to the master repository. Also, it's much faster than
SVN. And from what I hear, branching and merging support is a lot better
(which is to be expected, as these are the core reasons it was written)._

Perhaps that is a little harsh. I think the poster just doesn't understand
DVCS's.

~~~
m_mueller
Could you explain what's wrong with that answer? I found it to be spot on, but
then again maybe I'm 'clueless' as well.

~~~
chris_wot
The whole point of a DVCS is to be _decentralized_. Linus Torvalds often just
posts his own repository and others pull from it.

You can use it as a centralized repo, and it works quite well. In fact, it's
how I'm doing development with LibreOffice via gerrit. However, even there I
find it easier. I find my workflow is to work on a branch, make sure I have
clean commits (I use rebase pretty frequently) and branch and merge often.
Frankly, it's easier to work with. I find the staging model to be really
excellent, and find it just _easier_ to move up and down commits.

But looking at the quotes:

 _Git seems to be the "new, shiny, cool" thing._

No, no it's not.

 _Two modes of creating repositories_

Well, sure. It's literally just a shortcut for setting up groups and then
changing a global setting. Repos can go from bare to shared reasonably easily.
I fail to see the point.

 _checkout vs. clone_

Checkout checks out a branch of path to the working directory. Clone gets an
entire repository and "clones" it to the current directory. There is no
"versus" here, they are two _completely different_ operations.

 _commit vs. push_

Commit records the changes to the local repository. Push basically takes a ref
(a mapping to a sha-1 value that identifies a commit in the tree) and updates
a ref in a remote repository. In essence, you are pushing your changes to the
remote repository. Again, the thinking of a VCS person, not someone used to
DVCSes.

 _You have to know which commands work locally and which work with "the
server"_

Only if you think in terms of centralized repositories. A DVCS is
_distributed_. It's a completely different way of thinking. I find it superior
in very many ways.

 _Git has the advantage that it 's MUCH better suited if some developers are
not always connected to the master repository._

The whole _point_ of git is that you have your version, and you either pull
from or push to different repositories and and when needed. The whole idea of
centralization is not core to it at all.

~~~
einhverfr
> Only if you think in terms of centralized repositories. A DVCS is
> distributed. It's a completely different way of thinking. I find it superior
> in very many ways.

The benefits come at a cost though (I say this as someone who works with
both). For many environments, a centralized VCS is all you need. Making it
distributed just because that's a popular thing to do isn't necessarily always
a good idea. It complicates workflows because now you have to have multiple
version control systems which interact with eachother in far more complex
ways. You don't want to go down that path if you don't need to.

Now, despite the costs, there are many advantages to git. These include an
ability to effectively treat your local repo as a master for a client. Also
DVCS's scale to a larger number of developers more than traditional VCS's and
git has advantages there too.

BTW. one thing I find to be a killer feature of github is the fact that it
offers you svn access to git repos, which can be really, really nice.

~~~
nimblegorilla
> The benefits come at a cost though (I say this as someone who works with
> both). For many environments, a centralized VCS is all you need.

I'm having a hard time understanding what these extra "costs" are. I haven't
used SVN in a while, but I think the only extra cost is an extra command to
push your changes to a repository.

Meanwhile, the advantages of a distributed VCS are huge. Even if everyone is
developing on the same LAN it seems beneficial to have a DVCS. I've been on
multiple projects where the centralized VCS goes down for a day or even a
week. In that scenario everyone has to stop committing changes. Sharing
changes with a coworker now requires making a patch file or some other
cumbersome operation.

I can't think of a situation where a centralized VCS is better for any team.

~~~
einhverfr
I just find I end up spending quite a bit more time fighting with git than I
do svn. It may be anecdotal, but I find my workflows are _far_ more error
prone in git, and consequently they take a lot more overhead to ensure they
are right.

What you say might be true by at least accepted theory, and it is true that
command-line git (and git has a reputation of a bad command line) is the only
dcvs I have worked with but I don't see a way around the fact that since you
allow more complexity in interactions between repos, this is going to have
more overhead. Even you seem to acknowledge _twice_ as many commands for
version control management for the _simplest_ cases.

I am not really anti-git even. As I say I use it for some things. But I am not
at all convinced dvcs is always the right tool for the job.

~~~
nimblegorilla
> Even you seem to acknowledge twice as many commands for version control
> management for the simplest cases.

Well, I didn't really say that regarding the simplest cases. There is one
extra command to get something into the central repository, but basic
checkouts and updates from the repository are still one command.

I've gone through the "fighting" with git stage, but it was more because I was
trying to use concepts that aren't even possible with SVN rather than that git
makes things more complicated.

------
nahname
The second answer is pretty good.

Benefits:

-Works offline

-Branches/Merging

-Fork another's work

-Collaboration

-Light weight and fast

-Flexible

-Tooling (github)

Drawbacks of Git:

-Hard to learn if you know a centralized SCM.

~~~
kyrra
Drawback: if you are storing a lot of binary blobs, it will balloon the size
of a git repo quickly if those objects change often. While with SVN, users
only have to download the latest.

To add: there is a reason most game development shops use Perforce. Sometimes
you have to deal with large binary assets. Git is just the wrong answer in
that case.

------
flaxin
\- why is the sky blue?

\- why do birds sing in the morning?

here's why from G-O-D itself:
[http://www.youtube.com/watch?v=4XpnKHJAok8](http://www.youtube.com/watch?v=4XpnKHJAok8)

~~~
atmosx
I was curious to see if anyone posted this already :-)

Awesome talk by my favorite programmer :-P

------
benihana
_Why is iOS better than Android?_

 _Why is Linux better than OS X?_

 _Why is BMW better than Mercedes?_

 _Why are Pink Lady apples better than Granny Smith apples?_

 _Why is being an omnivore better than being a vegetarian?_

The way you answer all these questions will be the same. So whether you have
an answer or a process to answer these questions, you'll have a pretty good
idea about git vs svn.

~~~
Goladus
The form of the answer may be the same, but not the content. The idea that
answers are subject to preference and different needs doesn't mean a question
can not have objective answers.

