Practical Reasons To Choose Git Or Subversion?

markmcb writes "I develop Rails applications and recently followed my lemming herd and made the switch to Git after learning some of the practical advantages Git offers over Subversion. As I'm sure there are many die-hard Subversion fans in the Slashdot audience, I'm curious what your key reasons are for sticking with Subversion. If possible, I'd like reasons that apply to 'most of the time' as opposed to arguments based on obscure features that may get used only a few times ever."

Comments

Comment removed

[account_deleted]

Comment removed based on user account deletion

Linus on Git vs CVS/Subversion/Bitkeeper/etc

[MrFreezeBU]

How odd that I was just watching a talk that Linus gave at Google. Link to the talk

Re:Linus on Git vs CVS/Subversion/Bitkeeper/etc

[doug]

Randal Schwartz, the Perl guru, gave a more detailed presentation on git, also at google. It has a lot more meat on its bones, and gives examples of using git.

http://www.youtube.com/watch?v=8dhZ9BXQgc4

Git and SVN

[MemoryDragon]

Well hard decision, I live in both worlds, currently I use svn as central repo and git mainly for versioning local repos. Well both have their advantages and disadvantages. SVNs biggest disadvantage probably is the speed, and the model (which also is its biggest advantage for certain team structures) Gits biggest problems are: Almost total lack of tool integration into existing tools. Rather unstable and not well integrated into Windows. You have a load of data which resides on your filesystem (basically a full repo copy) while SVN keeps only parts of the metadata locally. Git however has the bigger advantage of having a very compact meta format so this disadvantage basically is nullified unless you have a huge codebase with thousands of revisions! I would not despise one or the other. I personally for a mixed team still would choose svn over git as it is currently, mainly due to the unpolished windows integration and lack of visual tool integration (yes git gui is known to me)

3d party tools - Trac and Tortoise

[Anonymous Coward]

Trac - One reason to use Subversion is the hard bindings you can get with Trac. Nothing enters the repository unless it is tied to a ticket. Ever been to a software process review? This is a must.
With the newer trac versions you can pass the tickets though the review stages and if you just wish to peer-review the code you can do that in Trac without checking out anything at all. Just click on the links in the ticket and you see a diff of the source in the webbrowser.

Tortoise - integration into Windows desktop. You can immediately tell by looking at the folder icons what needs to be checked in. Right click on a folder and select commit or update etc... For some reason this tools is so much better than anything on Linux...

Re:svn == unpleasant and maybe buggy

[CaptSaltyJack]

Subversion usability leaves a lot to be desired (although the book is really nice). For example, cd into a working copy that you've never seen before and try to determine its exact repository URL.

Uhh, ok.

$ cd tortoiseSVN
$ svn info
Path: .
URL: http://svn.collab.net/repos/svn/trunk
Repository Root: http://svn.collab.net/repos/svn
Repository UUID: 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
Revision: 33826
Node Kind: directory
Schedule: normal
Last Changed Author: hwright
Last Changed Rev: 33826
Last Changed Date: 2008-10-21 15:16:27 -0500 (Tue, 21 Oct 2008)

That was tough. I think I broke a sweat.

Re:IDE Integration

[Niten]

That's not to say git isn't awesome for certain situations, mind you. But branching and merging adds a fair bit of overhead, and anything that increases a project's overhead should be your last resort, not your first.

Well OK, those principles are appropriate for traditional tools like CVS and SVN. Branching and merging adds a lot of overhead if your SCM isn't built to handle it. But once you've used a modern SCM like Git or Bzr, you'll know that with Git you literally cannot branch too often. Don't think of Git branches like you think of Subversion branches, it's a whole different playing field.

I have a rule of thumb with Git: every time I set out to implement a new feature, if I think it's going to take more than a single commit to bring into the mainline, then I make a new branch for it. Working on three different features at the same time? Then use three different branches, and switch between them at will.

So what's the big difference between SVN and Git that allows such carefree use of branching? There are a few points to understand:

• At one point, the SVN developers liked to make a big deal out of the fact that branching in SVN is a lot cheaper than it is in CVS. That's all well and good, but it doesn't mean much when SVN's handling of merges is so primitive. Git handles merges extremely well, in no small part due to the fact that, like Bzr, Git tracks content rather than changes. (If you browse through the recent history of the Linux kernel, you can witness 12- and even 20-way merges; with Git, merging really is no big deal.)
• In Git (and in Bzr), branches are not immutable, permanent parts of your repository. You can delete (or simply not push) branches when you're done with them. This means you're free to make as many experimental branches as you like in your own local repository; you can take advantage of the full productivity power of Git branches without immortalizing your failed experiments in the central repo.
• In Git (and in Bzr, but not in Mercurial), there doesn't have to be a 1-1 mapping of named branches between each copy of your distributed repository. This has the important result that you can name your experimental branch "experiment" in your local repo, without being concerned about polluting some global branch namespace. This does a way with a lot of the mental overhead associated with branches in SVN.

In conclusion, 90% of the time I see people advocating the use of branches only as a last resort, it's because they're using the wrong SCM =)