

Why Subversion is better than Git - adrianmsmith
http://www.databasesandlife.com/why-subversion-is-better-than-git/

======
larrik
This should really be " _When_ Subversion is better than Git."

Git is better for programmers. The author seems to need something for everyone
else moreso. That's fine, but it doesn't make Subversion clearly better than
Git.

I do find "You can checkout only a subdirectory" really handy, though.

Edit: This article is fully 3 years old! That colors things a bit, though it
doesn't change my opinion.

------
jzoidberg
As a developer i love Git. I love its speed, its decentralized nature,
merging, branching. I even love submodules. We use git to deploy with - github
hooks lets us auto pull from all our ec2 servers - changes are globally
available in seconds.

As a collaborator i think it has failed us. I simply cant convince non-
programmers to learn it. People who only occasionally use versioning systems
simply do not need as much control. They need a much simplified layer over Git
- that prevents them from screwing up . I have tried SmartGit for this - not
simple enough, it still exposes the complexity.

------
bhousel
Really the #1 reason that Git beats Subversion right now, is that _Git is what
people use_. If your development involves any community open source stuff, you
will need to be comfortable with git and with github.

Just use git because it's what people use. There is no need to learn 2 things
when you can get by with just learning 1 thing. Spend your time on stuff
that's important.

------
cleaver
I've used both git and svn--probably a bit more time using git on the command
line. I wouldn't want to say that git is the best choice for every system, but
I've had more hair pulling with svn. Specifically, merging a commit from a
branch into trunk got messed up. I did find svn pretty painless when used with
Eclipse however.

The things about git that make me like it better are that the branching and
merging are easy and the distributed nature of the system. If your development
process doesn't exploit the features of git, then svn would be a reasonable
choice.

EDIT: Another key thing I like about git is that repos can be nested. The
parent repo simply ignores the child repos. This is something where I get a
lot of benefit.

------
LoneWolf
I never managed to find how do I revert changes in a file with git, I only
needed it once so far, and I had to ask a friend to do it for me, and I still
dont know how to do it, tried search how and it got me even more confused.

While I recognize it may have its advantages, I dont see them yet (except for
being distributed)

Note that I have not used git that much yet, maybe I just need to adapt to it
(the documentation does not help much either), but I adapted to subversion a
lot faster. Someone mentioned merges I had a few problems with them with
subversion, git never did one so I cant tell.

~~~
nessus42
_I never managed to find how do I revert changes in a file with git_

I'm not sure why anyone should think this hard to do. When you do "git status"
it even tells you how to do it:

    
    
        git checkout -- myFile
    

That will replace any changes to myFile that haven't been checked in yet with
the most recent version that was checked in. If you want to go back to an
older version, you can do

    
    
        git checkout a2791d14adf3 myFile
    

where that funky number is any unique prefix of the commit identifier that
"git log" shows you.

Well, that's if you haven't "staged" your changes. If you've staged the
changes, you have to "reset" the staging for the file first. I admit that this
staging thing is a bit confusing, so I rarely stage anything. There's no
reason that you need ever "stage" anything in Git if you don't want to, so I'm
not sure that that bit of extra complexity is worth worrying about.

~~~
LoneWolf
Thanks for that, spent a lot of time googling and never found that, maybe I
didnt search properly, the solutions I remember finding always involved more
than one command and were confusing.

------
kaerast
The problems you had when trying to switch to git are the exact same problems
I have as a git fangirl when trying to use svn. To a large extent the choice
of version control system comes down to what you feel happiest with, but there
are certain workflows which suit one or the other slightly better.

If you're making heavy use of svn externals then you'll find git submodules
pretty horrible. But if your aim is to manage files between multiple users
then git's distributed nature may make your life much easier if you give it
some more time.

------
GoldenMonkey
Coming from seven years of Subversion, I am amazed every time I 'cherry pick'
a fix in Git to another branch. Subversion could never do that, it's file
based versioning vs Git's content awareness is a paradigm shift. Subversion
now seems to be nothing more than a file backup system.

Linus Torvalds on Git: <http://www.youtube.com/watch?v=4XpnKHJAok8>

------
lightblade
Git, or any other distributed source control offers much richer tool set to
control your source code.

------
kirrmann
Great to read opinions about software from three years ago.

------
aliguori
tl;dr My manager can use TortoiseSVN and can't use git.

~~~
bobspryn
Get them a decent GUI for git. SourceTree for one is very nice. Or get a
manager that's willing to learn new things. :)

~~~
LoneWolf
Ahem... mac only, for a moment I had some hope there.

