Why Subversion is better than Git | Hacker News Reader

Why Subversion is better than Git

databasesandlife.com

15 pointsadrianmsmith17 comments

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.

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.

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.

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.

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.

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.

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.

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.

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

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

Great to read opinions about software from three years ago.

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

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

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

Do managers really need to use version control? Give them Dropbox if they just want to share files simply.

At least in the start-ups I work at, the team, who should have access to all the version-controlled files, is more than just developers.

There are the bosses who want to do a quick wording change, there are the wording guys, there are the designers changing images, there are the HTML people, there are the operations people, there are the translation people who are entering Arabic or Chinese strings into the translation files.

If they are not able to do these changes directly, they all have to go across a programmer's desk which is a waste of their time. Further, these other employees are not as empowered as they could be, to do changes themselves.

Sending such things to the developer as email attachments, meaning they have no idea which version had been changed, isn't this exactly the problem that version control was designed to solve?

It sounds like someone should make him or her a cheatsheet with the 3 commands that he needs to know.

Reply on news.ycombinator.com