tags:

views:

25003

answers:

30

I've been using Subversion for a few years and after using SourceSafe, I just love Subversion. Combined with TortoiseSVN, I can't really imagine how it could be any better.

Yet there's a growing number of developers claiming that Subversion has problems and that we should be moving to the new breed of distributed version control systems, such as Git.

How does Git improve upon Subversion?

+43  A: 

Google Tech Talk: Linus Torvalds on git

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

The Git Wiki's comparison page

http://git.or.cz/gitwiki/GitSvnComparsion

ESV
Linus' talk is fun to watch. He brutally rips centralized version control systems like Subversion and CVS. However, Randal Schwartz' http://www.youtube.com/watch?v=8dhZ9BXQgc4 talk is more constructive, more informative and more convincing.
bendin
This one is quite nice too. Its from one of the git commiters and he explains many advanced features like splitting large commits into smaller ones. http://www.youtube.com/watch?v=j45cs5_nY2k
schoetbi
+377  A: 

Git is not better than Subversion. But is also not worse. It's different.

The key difference is that it is decentralized. Imagine you are a developer on the road, you develop on your laptop and you want to have source control so that you can go back 3 hours.

With Subversion, you have a Problem: The SVN Repository may be in a location you can't reach (in your company, and you don't have internet at the moment), you cannot commit. If you want to make a copy of your code, you have to literally copy/paste it.

With Git, you do not have this problem. Your local copy is a repository, and you can commit to it and get all benefits of source control. When you regain connectivity to the main repository, you can commit against it.

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

Git seems to be the "new, shiny, cool" thing. It's by no means bad (there is a reason Linus wrote it for the Linux Kernel development after all), but I feel that many people jump on the "Distributed Source Control" train just because it's new and is written by Linus Torvalds, without actually knowing why/if it's better.

Subversion has Problems, but so does Git, Mercurial, CVS, TFS or whatever.

Edit: So this answer is now a year old and still generates many upvotes, so I thought I'll add some more explanations. In the last year since writing this, Git has gained a lot of momentum and support, particularly since sites like GitHub really took off. I'm using both Git and Subversion nowadays and I'd like to share some personal insight.

First of all, Git can be really confusing at first when working decentralized. What is a remote? and How to properly set up the initial repository? are two questions that come up at the beginning, especially compared to SVN's simple "svnadmin create", Git's "git init" can take the parameters --bare and --shared which seems to be the "proper" way to set up a centralized repository. There are reasons for this, but it adds complexity. The documentation of the "checkout" command is very confusing to people changing over - the "proper" way seems to be "git clone", while "git checkout" seems to switch branches.

Git REALLY shines when you are decentralized. I have a server at home and a Laptop on the road, and SVN simply doesn't work well here. With SVN, I can't have local source control if I'm not connected to the repository (Yes, I know about SVK or about ways to copy the repo). With Git, that's the default mode anyway. It's an extra command though (git commit commits locally, whereas git push origin master pushes the master branch to the remote named "origin").

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").

Also, the tooling is still insufficient, at least on Windows. Yes, there is a Visual Studio AddIn, but I still use git bash with msysgit.

SVN has the advantage that it's MUCH simpler to learn: There is your repository, all changes to towards it, if you know how to create, commit and checkout and you're ready to go and can pickup stuff like branching, update etc. later on.

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).

This also explains why it gains so much buzz on the Internet, as Git is perfectly suited for Open Source projects: Just Fork it, commit your changes to your own Fork, and then ask the original project maintainer to pull your changes. With Git, this just works. Really, try it on Github, it's magic.

What I also see are Git-SVN Bridges: The central repository is a Subversion repo, but developers locally work with Git and the bridge then pushes their changes to SVN.

But even with this lengthy addition, I still stand by my core message: Git is not better or worse, it's just different. If you have the need for "Offline Source Control" and the willingness to spend some extra time learning it, it's fantastic. But if you have a strictly centralized Source Control and/or are struggling to introduce Source Control in the first place because your co-workers are not interested, then the simplicity and excellent tooling (at least on Windows) of SVN shine.

Michael Stum
A Ferrari is not better than a Hyundai. But is also not worse. It's different. (What? Don't stare ME this way... Did I say something wrong?)
F.D.Castel
No, you didn't. A Ferrari is impractical, expensive, thirsty, and will not get you better from A to B if you live in a city like New York or Paris - I'd prefer a Hyundai for many places, also because a scratch is much less severe. But to each his own - a Ferrari has (very few) advantages as well...
Michael Stum
Good summary - I use Subversion myself, and have no real need (that I can perceive) to move to git - I think you may be correct regarding the swathes of developers moving to it just because it's in vogue at the moment.
Rob
Distribution is not the only difference between Subversion and Git. It also doesn't add any complexity unless you use multiple repositories.There are _many_ advantages of using Git instead of Subversion, but only a few (mostly insignificant) disadvantages. Git is used because it's good, not shiny.
sebnow
That's the conclusion if you really spent some time investigating it AND if you have the tools for it (Sure, you have to know all the command line tools of your CVS, but that does not mean that people really like to use them all the time). As said, many people (i know) said Git = Good because Linus
Michael Stum
I also think GIT advocacy could take this to heart. You can hammer on principles and who is using it for years, but after the first time that is filtered out. It could use a more practical explanation (like how the workflow typically looks like) instead of the abstract discussions.
Marco van de Voort
@Michael Stum - You've obviously never driven a Ferrari. :)
Dana Holt
I'm amazed this is the top voted answer! (AFAICT from git affectionados) git is not just svn with offline - its a whole new life-changing revelation. I suspect this was voted up by svn fans sick of hearing about how great git is.
Paul Biggar
My experiences with git aren't exactly a "Life changing revelation". I consider it a great tool when it works, when when it doesn't then it feels rather unpolished. I wasn't too impressed debugging stuff like Question 1052882, and even though that is clearly an RTFM Problem: I do consider git (and any other distributed vcs) to be more complicated than centralized ones, and I would consider using it in centralized environments. But then again, i'm mainly a Windows developer, and the tools are still immature on Windows compared to SVN.
Michael Stum
Newflash: People other than developers use revision control systems.Look, I'm sure git is the second coming, but as an svn admin, we have non-developers using it (mostly through TortoiseSVN), and I'm 99% sure that if our developers demanded git, I'd be maintaining 2 revision control systems instead of one. As an aside: how many issue and bug tracking systems allow multiple RCS to be configured?
Si
I've made a few additions, as the last 12 months really sold me on Git. It's still a very steep learning curve and the tooling isn't exactly great on Windows, but once learned it's excellent. I don't want to sound like an advertiser, but TekPub's Mastering Git series helped me understanding it, especially the (for me) hard and critical thing about "How Remotes work".
Michael Stum
@Michael: what's different about software is that cloning costs nothing (almost). Therefore, only one design has a right to live. There's virtually no market to share, which is why it is not like cars.
Pavel Radzivilovsky
@dana I also prefer a Hayabusa =x
Pavel Radzivilovsky
The question was "Why is git better?", and the most upvoted (and selected) answer starts with "Git is not better." Hilarious.
Mark Beckwith
About these Ferrari comments... A straight answer, please... If I switch from svn to git, will it impress women? Will people think I'm rich and cool? Or... when I go on about it, will everyone think I'm even more of a gigantic dork than they do already?
Steve314
It should be noted that Jira allows more than one repository and more than one type of repo to be configured at a time for those that are interested or have different needs for revision control.
krystan honour
"Git is not better than Subversion", that's just plain WRONG. git is better by heaps and bounds.
hasen j
@hasen Only if you get over the much steeper learning curve. I absolutely love it, But in environments where you still have to sell the concept of Source Control to your devs (which most of the time means a Windows using development shop), SVNs superior tooling and simplicity simply beats git by miles. If (and that's an "if", not a "when") your devs are really using Source Control, then git can start to shine. I would never use SVN again, but a ton of people would never use Git if it doesn't properly integrate into their tools and if they don't understand the concept.
Michael Stum
@Michael Stum: the "git is hard" meme is totally a myth. I find git to be a lot easier than svn. I never really understood subversion; git just makes sense. Though I agree with you @ it can be a bit harder to sell to the windows guys.
hasen j
OP seems to be confused about Git, or I'm misunderstanding. There aren't "two modes of creating repos," `git clone` ~~ `svn co`, `git push` ~~ `svn ci`, `git commit` ~~ `svn add/rm/etc`. Git is only difficult to learn if you have preconceptions of how VCS work. I started with mercurial, went to git, and then had to learn SVN. Guess which was the most difficult to use? SVN! I started using git-svn because SVN is so horrible. There's nothing "proper" about how svn uses the term "checkout".
sebnow
@sebnow I was referring to `git init` vs. `git init --bare`
Michael Stum
Ah, in that case I would assume `svnadmin create` ~~ `git init --bare`. The only difference between `--bare` and normal is that a normal repo has a working directory (files are checked out). This is typically only used as a server/central repository and can be ignored by the typical user. In that sense, SVN has "two" ways of creating repos as well; `svnadmin create` and `svn co`.
sebnow
Ferrari could be a good if you want to impress some girls or you can choose a dirt bike if you really need mobility.
Sorin Sbarnea
@steve314: Sorry for the late response. The type of woman who is impressed by your car or choice of VCS is shallow and likely to be high-maintenance. She'll drop you in a heartbeat for a guy with some new-fangled quantum-entangled VCS that makes your commits instantly available in all copies.
Hugh Brackett
You only analyse the distribution aspect in the comparison. I'll tell you why. Because you only want to *share* code. Git and SVN are more than that, have you ever tagged, branched, merged, resolved conflicts, copy patches among branches? I think your analysis is just flawed. In those aspects, git is a MUCH powerful tool. Not to mention things that git can, and SVN can't, like squashing, disecting, ammending, rebasing, cherry-picking, and much more things.
mrrtnn
Uh, you can just host a svn server on your local computer?
Nico
+25  A: 

Well, it's distributed. Benchmarks indicate that it's considerably faster (given its distributed nature, operations like diffs and logs are all local so of course it's blazingly faster in this case), and working folders are smaller (which still blows my mind).

When you're working on subversion, or any other client/server revision control system, you essentially create working copies on your machine by checking-out revisions. This represents a snapshot in time of what the repository looks like. You update your working copy via updates, and you update the repository via commits.

With a distributed version control, you don't have a snapshot, but rather the entire codebase. Wanna do a diff with a 3 month old version? No problem, the 3 month old version is still on your computer. This doesn't only mean things are way faster, but if you're disconnected from your central server, you can still do many of the operations you're used to. In other words, you don't just have a snapshot of a given revision, but the entire codebase.

You'd think that Git would take up a bunch of space on your harddrive, but from a couple benchmarks I've seen, it actually takes less. Don't ask me how. I mean, it was built by Linus, he knows a thing or two about filesystems I guess.

Karl Seguin
The cause why Git can take less disk space for full repository than Subversion for mere checkout is that Subversion stores "pristine copy" to make 'svn diff' (comparision with last version) work... and that git repository is compressed (and deltaified).
Jakub Narębski
I am not surprised git "working folders" (i.e., repos) are smaller than svn working copies because even svn repos are smaller than svn working copies.
Martinho Fernandes
+5  A: 

Git and DVCS in general is great for developers doing a lot of coding independently of each other because everyone has their own branch. If you need a change from someone else, though, she has to commit to her local repo and then she must push that changeset to you or you must pull it from her.

My own reasoning also makes me think DVCS makes things harder for QA and release management if you do things like centralized releases. Someone has to be responsible for doing that push/pull from everyone else's repository, resolving any conflicts that would have been resolved at initial commit time before, then doing the build, and then having all the other developers re-sync their repos.

All of this can be addressed with human processes, of course; DVCS just broke something that was fixed by centralized version control in order to provide some new conveniences.

jaredg
Actually if you look like Linux kernel or git project itself is managed, you would see that Git is very good for 'single maintainer' (or maintainer + lieutenants) workflow, with one central by consens repository. And it makes easy to switch temporaritly to someone else as a maintainer.
Jakub Narębski
+6  A: 

It's all about the ease of use/steps required to do something.

If I'm developing a single project on my PC/laptop, git is better, because it is far easier to set up and use. You don't need a server, and you don't need to keep typing repository URL's in when you do merges.

If it were just 2 people, I'd say git is also easier, because you can just push and pull from eachother.

Once you get beyond that though, I'd go for subversion, because at that point you need to set up a 'dedicated' server or location.

You can do this just as well with git as with SVN, but the benefits of git get outweighed by the need to do additional steps to synch with a central server. In SVN you just commit. In git you have to git commit, then git push. The additional step gets annoying simply because you end up doing it so much.

SVN also has the benefit of better GUI tools, however the git ecosystem seems to be catching up quickly, so I wouldn't worry about this in the long term.

Orion Edwards
The separation of committing from publishing in Git is IMHO advantage rather than disadvantage.
Jakub Narębski
Ok, so how would you rate the "ease of use/steps required to do something" for SVN when:- making a topic branch for experimentation- merging this branch into another branch- splitting edited stuff in a file into their own smaller commits- quickly checking out a main branch to make a small fixIMHO I don't see how setting up an SVN server is easier than setting up your git server. And why you'd want to give up all the nice advantages you get from lightweight branches just so you don't "have to push separately".
Sam
The "topic branch for experimentation" argument is often put forward in git's favour, but honestly, I've never actually seen anyone actually *do* that in subversion or another non-DVCS system. Perhaps it's a big deal and we're all missing out, but from what I've seen 99% of developers (myself included) don't care about topic branches because they never use them! - You can't miss what you've never had :-). I think if DVCS people are going to put forward "topic branches" as a feature, they **first** have to convince everyone that such things are actually useful.
Orion Edwards
The "splitting edited stuff into smaller commits", again, is something that sounds nice in theory. But, in the last 3 years, I've *not once* thought "oh, I wish I could do that", and I struggle to even come up with a hypothetical situation where I might want the feature... A lot of the git/DVCS advocates simply say "we have X and X is awesome" and everyone else is sitting there wondering why on earth they'd ever need X
Orion Edwards
+114  A: 

With Git, you can do practically anything offline, because everybody has their own repository.

Making branches and merging between branches is really easy.

Even if you don't have commit rights for a project, you can still have your own repository online, and publish "push requests" for your patches. Everybody who likes your patches can pull them into their project, including the official maintainers.

It's trivial to fork a project, modify it, and still keep merging in the bugfixes from the HEAD branch.

Git works for the Linux kernel developers. That means it is really fast (it has to be), and scales to thousands of contributors. Git also uses less space (up to 30 times less space for the Mozilla repository).

Git is very flexible, very TIMTOWTDI (There is more than one way to do it). You can use whatever workflow you want, and Git will support it.

Finally, there's GitHub, a great site for hosting your Git repositories.

Drawbacks of Git:

  • it's much harder to learn, because Git has more concepts and more commands.
  • revisions don't have version numbers like in subversion
  • many Git commands are cryptic, and error messages are very user-unfriendly
  • it lacks a good GUI (such as the great TortoiseSVN)
Michiel de Mare
Although learning all of Git would be much harder, the basics are almost identical. The learning scope isn't really that steep until you get into the more advanced stuff, which SVN is simply not capable of anyway.
sebnow
+1 for me. I think a lot of developers forget that git is lacking something like TortoiseSVN, and that not only developers use version control. I shudder at the thought of having to explain (and support) distributed version control to our non-developers using SVN|TortoiseSVN!
Si
I'm SVN user, but - try this: http://code.google.com/p/tortoisegit/
DiGi
another disadvantage - you have to have a full copy of the repository, you can't work on partials (which matters if you have huge ones, like a lot of corporates)
gbjbaanb
I love git, but it took me about six months of daily use to really use it effectively. That being said, I use a combination of the git shell (command prompt) from msysgit, git gui and gitk from msysgit, and TortoiseGit. I think TortoiseGit is great, but I don't understand why more people don't use it. I know the msysgit maintainers loath TortoiseGit for various reasons, some of them ideological, and that may have something to do with it. TortoiseGit is a well-kept secret!
Jim Raden
I agree. I use both SVN and GIT (since about 6 months). I honestly love git a lot more than I ever did SVN. It just takes time to learn it. The biggest leap for me (the moment I saw the light :P) was when I finally realized I had to stop trying to use GIT the way SVN worked. Then everything fell in place ;)
Blizz
Hey? What's this "offline" thing I keep hearing about?
KarlP
@Karlp: You don't need to connect to a server to use **Git**.
Josh
+7  A: 

Git also makes branching and merging really easy. Subversion 1.5 just added merge tracking, but Git is still better. With Git branching is very fast and cheap. It makes creating a branch for each new feature more feasible. Oh and Git repositories are very efficient with storage space as compared to Subversion.

ejunker
+6  A: 

Easy Git has a nice page comparing actual usage of Git and SVN which will give you an idea of what things Git can do (or do more easily) compared to SVN. (Technically, this is based on Easy Git, which is a lightweight wrapper on top of Git.)

Pat Notz
+5  A: 

One of the things about SubVersion that irks me is that it puts its own folder in each directory of a project, whereas git only puts one in the root directory. It's not that big of a deal, but little things like that add up.

Of course, SubVersion has Tortoise, which is [usually] very nice.

swilliams
the .svn dirs will be gone soon, probably with v1.7
gbjbaanb
+3  A: 

Thanks to the fact it doesn't need to communicate with a central server constantly, pretty much every command runs in less than a second (obviously git push/pull/fetch are slower simply because they have to initalise SSH connections). Branching is far far easier (one simple command to branch, one simple command to merge)

dbr
+16  A: 

The main points I like about DVCS are those :

  1. You can commit broken things. It doesn't matter because other peoples won't see them until you commit. Publish time is different of commit time.
  2. Because of this you can commit more often.
  3. You can merge complete functionnality. This functionnality will have its own branch. All commits of this branch will be related to this functionnality. You can do it with a CVCS however with DVCS its the default.
  4. You can search your history (find when a function changed )
  5. You can undo a pull if someone screw up the main repository, you don't need to fix the errors. Just clear the merge.
  6. When you need a source control in any directory do : git init . and you can commit, undoing changes, etc...
  7. It's fast (even on Windows )

The main reason for a relatively big project is the improved communication created by the point 3. Others are nice bonuses.

Emmanuel Caradec
+9  A: 

Subversion is still a much more used version control system, which means that it has better tool support. You'll find mature SVN plugins for almost any IDE, and there are good explorer extensions available (like TurtoiseSVN). Other than that, I'll have to agree with Michael: Git isn't better or worse than Subversion, it's different.

neu242
+77  A: 

Other answers have done a good job of explaining the core features of Git (which are great). But there's also so many little ways that Git behaves better and helps keep my life more sane. Here are some of the little things:

  1. Git has a 'clean' command. SVN desperately needs this command, considering how frequently it will dump extra files on your disk.
  2. Git has the 'bisect' command. It's nice.
  3. SVN creates .svn directories in every single folder (Git only creates one .git directory). Every script you write, and every grep you do, will need to be written to ignore these .svn directories. You also need an entire command ("svn export") just to get a sane copy of your files.
  4. In SVN, each file & folder can come from a different revision or branch. At first, it sounds nice to have this freedom. But what this actually means is that there is a million different ways for your local checkout to be completely screwed up. (for example, if "svn switch" fails halfway through, or if you enter a command wrong). And the worst part is: if you ever get into a situation where some of your files are coming from one place, and some of them from another, the "svn status" will tell you that everything is normal. You'll need to do "svn info" on each file/directory to discover how weird things are. If "git status" tells you that things are normal, then you can trust that things really are normal.
  5. You have to tell SVN whenever you move or delete something. Git will just figure it out.
  6. Ignore semantics are easier in Git. If you ignore a pattern (such as *.pyc), it will be ignored for all subdirectories. (But if you really want to ignore something for just one directory, you can). With SVN, it seems that there is no easy way to ignore a pattern across all subdirectories.
  7. Another item involving ignore files. Git makes it possible to have "private" ignore settings (using the file .git/info/exclude), which won't affect anyone else.
andy
Ad. 7. With modern git you can also have per-user "private" ignore setting by using core.excludesFile configuration variable in ~.gitignore (see man git-config).
Jakub Narębski
Re #5: While this is normally true, sometimes Git does screw this up. At least with Subversion, problems due to move or delete are almost invariably a PEBKAC. While it's nice to have automatic move/delete tracking, I'd still at least appreciate the ability to explicitly state what I'm doing to files in the repository, even if I don't need to use it.
Chris Charabaruk
@Chris: You can do it explicitely: `git mv` and `git rm`.
Martinho Fernandes
I would also like to see the option of a single .svn directory per working copy, but for the record:For #3: Most tools will (by default) ignore .svn directories.For #6: You can set properties recursively.
Si
3: "a single .svn" directory will be here with SVN 1.7 when WC-NG is implememnted. 1: To get SVN cleanup you 'export' over the top of your WC. 5: its not so easy, if you rename a file does git recognise it and keep history, or treat it as an add and delete in the directory?. 6/7: svn has global-ignores per user client setting.
gbjbaanb
I have faced problems #4, #6 and #7 with svn. +1 for pointing them out w.r.t. git.
Sushant
Re: #3 "every grep you do": you need "ack": http://betterthangrep.com/
janmoesen
I don't understand how #3 and #5 are both true... it seems like me that the point of having an .svn in every folder would be to seamlessly move stuff, and with one central location it is much harder to track movements...
Dan
+14  A: 

The funny thing is: I host projects in Subversion Repos, but access them via the Git Clone command.

Please read Develop with Git on a Google Code Project

Although Google Code natively speaks Subversion, you can easily use Git during development. Searching for "git svn" suggests this practice is widespread, and we too encourage you to experiment with it.

Using Git on a Svn Repository gives me benefits:

  1. I can work distributed on several machines, commiting and pulling from and to them
  2. I have a central backup/public svn repository for others to check out
  3. And they are free to use Git for their own
Andre Bossard
this is kind of out of date, google code does mercurial so there is not need for this hack anymore
Sam Saffron
+4  A: 

I like Git because it actually helps communication developer to developer on a medium to large team. As a distributed version control system, through its push/pull system, it helps developers to create a source code eco-system which helps to manage a large pool of developers working on a single project.

For example say you trust 5 developers and only pull codes from their repository. Each of those developers has their own trust network from where they pull codes. Thus the development is based on that trust fabric of developers where code responsibility is shared among the development community.

Of course there are other benefits which are mentioned in other answers here.

Mozammel
+37  A: 

"Why Git is Better than X" outlines the various pros and cons of Git vs other SCMs.

Briefly:

  • Git tracks content rather than files
  • Branches are lightweight and merging is easy, and I mean really easy.
  • It's distributed, basically every repository is a branch. It's much easier to develop concurrently and collaboratively than with Subversion, in my opinion. It also makes offline development possible.
  • It doesn't impose any workflow, as seen on the above linked website, there are many workflows possible with Git. A Subversion-style workflow is easily mimicked.
  • Git repositories are much smaller in file size than Subversion repositories. There's only one ".git" directory, as opposed to dozens of ".SVN" repositories.
  • The staging area is awesome, it allows you to see the changes you will commit, commit partial changes and do various other stuff.
  • Stashing is invaluable when you do "chaotic" development, or simply want to fix a bug while you're still working on something else (on a different branch).
  • You can rewrite history, which is great for preparing patch sets and fixing your mistakes (before you publish the commits)
  • … and a lot more.

There are some disadvantages:

  • There aren't many good GUIs for it yet. It's new and Subversion has been around for a lot longer, so this is natural and there are a few interfaces in development.
  • Partial checkouts/clones of repositories are not possible at the moment (I read that it's in development). However, there is submodule support.
  • It might be harder to learn, even though I did not find this to be the case (about a year ago). Git has recently improved its interface and is quite user friendly.

In the most simplistic usage, Subversion and Git are pretty much the same. There isn't much difference between:

svn checkout svn://foo.com/bar bar
cd bar
# edit
svn commit -m "foo"

and

git clone [email protected]:foo/bar.git
cd bar
# edit
git commit -a -m "foo"
git push

Where Git really shines is branching and working with other people.

sebnow
You say GIT tracks content rather than files. I discovered that SVN also does that: I just made changes to a file, and saved it. SVN showed the file as red(changed). Then I did undo in the editor and saved it again. SVN then updated the status to green (not changed) even if the file was changed (change date newer) but SVN recognised that the content was not changed from the original.
awe
does svn track changes accross files?
Seun Osewa
@awe, that's called file tracking. try renaming the file, or moving it somewhere else manually [same content, new file (because of the new path/name)]: will SVN know that that's the same file and retain the previous countless revisions you've made to it? no, I guess not.
kRON
TortoiseGit - http://code.google.com/p/tortoisegit/ **|** Git 1.7 sparse checkouts - http://www.kernel.org/pub/software/scm/git/docs/RelNotes-1.7.0.txt
Josh
+4  A: 

A few answers have alluded to these, but I want to make 2 points explicit:

1) The ability to do selective commits (for example, git add --patch). If your working directory contains multiple changes that are not part of the same logical change, Git makes it very easy to make a commit that includes only a portion of the changes. With Subversion, it is difficult.

2) The ability to commit without making the change public. In Subversion, any commit is immediately public, and thus irrevocable. This greatly limits the ability of the developer to "commit early, commit often".

Git is more than just a VCS; it's also a tool for developing patches. Subversion is merely a VCS.

William Pursell
Re 1) If you're using TortoiseSVN, AnkhSVN, etc. then it's very easily (trivial) to select which files with changes to commit. Re 2) If you don't want other devs to get your code, create a branch and then merge when ready, it's not hard.
Si
irrevocable? Well you could reverse merge the faulty commit and the repository is as it was before. But you are right it is documented. But is this good or bad? I guess it depends...
schoetbi
+9  A: 

All the answers here are as expected, programmer centric, however what happens if your company uses revision control outside of source code? There are plenty of documents which aren't source code which benefit from version control, and should live close to code and not in another CMS. Most programmers don't work in isolation - we work for companies as part of a team.

With that in mind, compare ease of use, in both client tooling and training, between Subversion and git. I can't see a scenario where any distributed revision control system is going to be easier to use or explain to a non-programmer. I'd love to be proven wrong, because then I'd be able to evaluate git and actually have a hope of it being accepted by people who need version control who aren't programmers.

Even then, if asked by management why we should move from a centralised to distributed revision control system, I'd be hard pressed to give an honest answer, because we don't need it.

Disclaimer: I became interested in Subversion early on (around v0.29) so obviously I'm biased, but the companies I've worked for since that time are benefiting from my enthusiasm because I've encouraged and supported its use. I suspect this is how it happens with most software companies. With so many programmers jumping on the git bandwagon, I wonder how many companies are going to miss out on the benefits of using version control outside of source code? Even if you have separate systems for different teams, you're missing out on some of the benefits, such as (unified) issue tracking integration, whilst increasing maintenance, hardware and training requirements.

Si
IMHO, this is the only valid reason to favour SVN. In short, it's easier to explain to a non-programmer, that is, someone who expected to use it in a linear way and avoid complex (=real) VC scenarios: conflicts, 3 way merges,branches.. I mean, you would never want to let the VCS merge a powerpoint presentation file anyway..
inger
"Most programmers don't work in isolation" seems to suggest that accountants/marketing people would have to use the same repo where the source code is kept. I don't see the benefits of this; some my ex companies wanted to standardize on things like that, but it inevitably failed. I think the simplistic approach can be great for manager but an oversimplification for programmer teams - so unifying these leads to a bad compromise.
inger
For documents that go with the software, you're right - they should be versioned together. I found that those much less than people think initially (we ended up throwing out a huge tree docs from the source repo). Also, there is a lot you can do to simplify workflows of tech writers, etc, should it be an issue (it should not).
inger
@inger I don't think you can say "this is the only valid reason", AFAIK tooling support for Subversion is far superior to Git, e.g. TortoiseSVN and integration with Visual Studio and Java IDE like Eclipse. That may not be an issue for you, but it certainly is for us. I didn't mentioned it in my answer because it's a separate issue.
Si
+1  A: 

Subversion is very easy to use. I have never found in the last years a problem or that something doesn't work as expected. Also there are many excellent GUI tools and the support for SVN integration is big.

With Git you get a more flexible VCS. You can use it the same way like SVN with a remote repository where you commit all changes. But you can also use it mostly offline and only push the changes from time to time to the remote repository. But Git is more complex and has a steeper learning curve. I found myself in the first time committing to wrong branches, creating branches indirectly or get error messages with not much informations about the mistake and where I must search with Google to get better informations. Some easy things like substitution of markers ($Id$) doesn't work but GIT has a very flexible filtering and hook mechanism to merge own scripts and so you get all things you need and more but it needs more time and reading of the documentation ;)

If you work mostly offline with your local repository you have no backup if something is lost on your local machine. With SVN you are mostly working with a remote repository which is also the same time your backup on another server... Git can work in the same way but this was not the main goal of Linus to have something like SVN2. It was designed for the Linux kernel developers and the needs of a distributed version control system.

Is Git better then SVN? Developers which needs only some version history and a backup mechanism have a good and easy life with SVN. Developers working often with branches, testing more versions at the same time or working mostly offline can benefit from the features of Git. There are some very useful features like stashing not found with SVN which can make the life easier. But on the other side not all people will need all features. So I cannot see the dead of SVN.

Git needs some better documentation and the error reporting must be more helpful. Also the existing useful GUIs are only rarely. This time I have only found 1 GUI for Linux with support of most Git features (git-cola). Eclipse integration is working but its not official released and there is no official update site (only some external update site with periodical builds from the trunk http://www.jgit.org/updates) So the most preferred way to use Git this days is the command line.

devarni
+2  A: 

Eric Sink from SourceGear wrote series of articles on differences between distributed and nondistributed version controls systems. He compares pros and cons of most popular version control systems. Very interesting reading.
Articles can be found on his blog, www.ericsink.com:

zendar
+2  A: 
  • Git works offline
  • Subversion supports externals

Git lost.

(And don't even start about manual pulls/pushes of "externals" in git).

Andreas
Git has submodules, which are externals done right ;-)
Jakub Narębski
A: 

First, concurrent version control seems like an easy problem to solve. It's not at all. Anyway...

SVN is quite non-intuitive. Git is even worse. [sarcastic-speculation] This might be because developers, that like hard problems like concurrent version control, don't have much interest in making a good UI. [/sarcastic-speculation]

SVN supporters think they don't need a distributed version-control system. I thought that too. But now that we use Git exclusively, I'm a believer. Now version control works for me AND the team/project instead of just working for the project. When I need a branch, I branch. Sometimes it's a branch that has a corresponding branch on the server, and sometimes it does not. Not to mention all the other advantages that I'll have to go study up on (thanks in part to the arcane and absurd lack of UI that is a modern version control system).

Yar
A: 

Git in Windows is quite well supported now.

Check out GitExtensions = http://code.google.com/p/gitextensions/

and the manual for a better Windows Git experience.

Arnold
+1  A: 

http://subversion.wandisco.com/component/content/article/1/40.html

I think it's fairly safe to say that amongst developers, the SVN Vs. Git argument has been raging for some time now, with everyone having their own view on which is better. This was even brought up in the of the questions during our Webinar on Subversion in 2010 and Beyond.

Hyrum Wright, our Director of Open Source and the President for the Subversion Corporation talks about the differences between Subversion and Git, along with other Distributed Version Control Systems (DVCS).

He also talks about the upcoming changes in Subversion, such as Working Copy Next Generation (WC-NG), which he believes will cause a number of Git users to convert back to Subversion.

Have a watch of his video and let us know what you think by either commenting on this blog, or by posting in our forums. Registration is simple and will only take a moment!

Elaine Murphy
Obviously biased, as his tool is based on Subversion. Just saying.
Jakub Narębski
+2  A: 

I absolutely love being able to manage local branches of my source code in Git without muddying up the water of the central repository. In many cases I'll checkout code from the Subversion server and run a local Git repository just to be able to do this. It's also great that initializing a Git repository doesn't pollute the filesystem with a bunch of annoying .svn folders everywhere.

And as far as Windows tool support, TortoiseGit handles the basics very well, but I still prefer the command line unless I want to view the log. I really like the way Tortoise{Git|SVN} helps when reading commit logs.

Matt Hulse
A: 

I have been dwelling in Git land lately, and I like it for personal projects, but I wouldn't be able to switch work projects to it yet from Subversion given the change in thinking of required from staff, without no pressing benefits. Moreover the biggest project we run in-house is extremely dependent on svn:externals which, from what I've seen so far, does not work so nicely and seamlessly in Git.

haknick
+2  A: 

I think Subversion is fine.. until you start merging.. or doing anything complicated.. or doing anything Subversion thinks is complicated (like doing queries to find out which branches messed with a particular file, where a change actually comes from, detecting copy&pastes, etc)...

I disagree with the winning answer, saying the main benefit of GIT is offline work - it's certainly useful, but it's more like an extra for my use case. SVK can work offline too, still there is no question for me which one to invest my learning time in).

It's just that it's incredibly powerful and fast and, well -after getting used to the concepts - very useful (yes, in that sense: user friendly).

For more details on a merging story, see this : http://stackoverflow.com/questions/2945842/using-git-svn-or-similar-just-to-help-out-with-svn-merge/2981745#2981745

inger
+5  A: 

David Richards WANdisco Blog on Subversion / GIT

The emergence of GIT has brought with it a breed of DVCS fundamentalists – the ‘Gitterons’ – that think anything other than GIT is crap. The Gitterons seem to think software engineering happens on their own island and often forget that most organizations don’t employ senior software engineers exclusively. That’s ok but it’s not how the rest of the market thinks, and I am happy to prove it: GIT, at the last look had less than three per cent of the market while Subversion has in the region of five million users and about half of the overall market.

The problem we saw was that the Gitterons were firing (cheap) shots at Subversion. Tweets like “Subversion is so [slow/crappy/restrictive/doesn't smell good/looks at me in a funny way] and now I have GIT and [everything works in my life/my wife got pregnant/I got a girlfriend after 30 years of trying/I won six times running on the blackjack table]. You get the picture.

Elaine Murphy
Note that David Richards could be unbiased: the product he makes is based on Subversion (or on Subversion ideas), so of course he would be pro-Subversion and anti-Git.
Jakub Narębski
+2  A: 

Why I think Subversion is better than Git (at least for the projects I work on), mainly due to its usability, and simpler workflow:

http://www.databasesandlife.com/why-subversion-is-better-than-git/

Adrian Smith
A: 

Why is it better? I'll tell you why. It just works.

mrrtnn