Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I want to choose a version control system for my company. So far I know I have Git, Subversion and Mercurial.

These days I see that Git is the most used, so I'm left wondering: would there be any specific reason to still use Subversion, or should I go directly to Git?

share|improve this question

closed as not constructive by gnat, Walter, gbjbaanb, Matthieu, ChrisF Sep 4 '12 at 7:49

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

36  
They both work. The important thing is whether they'll meet your requirements, which you haven't told us. –  Matthew Flynn Sep 3 '12 at 5:38
6  
See Why to use SVN? Any hidden pros (over GIT/Mercurial/Bazaar) there? on Stack Overflow. –  detly Sep 3 '12 at 7:27
11  
On which argument do you exclude Mercurial? –  mouviciel Sep 3 '12 at 8:55
8  
-1 for subjective (baiting IMHO) wording and "Those days I see that Git is the most used" - citation needed. Git is extremely common in the open source world, but in the corporate space it's much rarer. Corps really like the idea of a single, central, authoritative repository and are very slow to change. In the corporate space you're more likely to see good ole CVS than SVN even, never mind a DVCS. –  Keith Sep 3 '12 at 13:31
4  
@RobinWinslow - SVN is different from Git. Better suited to some circumstances and worse suited to others. Personally I prefer DVCS in general and you obviously prefer Git, but both of those are subjective opinions. They're not without value, but they don't belong on a site like this. –  Keith Sep 4 '12 at 7:35

6 Answers 6

SVN is not dead at all. It's is still in extremely wide use, and it's not going anywhere anytime soon. SVN is much simpler to use than distributed version control, especially if you're not actually running a distributed project that needs distributed version control.

If you only have one central repository (which is all your company will need if they're still small enough to get by without source control so far), it's much simpler to use SVN to interact with it. For example, with SVN you can pull changes from the repository, or commit your local changes to it, with a single operation, whereas HG and Git require two or three steps to do the equivalent work.

And with the recent revisions, SVN has fixed a lot of the performance issues that made people prefer HG and Git. It's significantly faster now than it was a couple years ago, and at this point, there's really no good reason to look at HG or Git for your project unless you actually need the advanced features of distributed version control.

share|improve this answer
16  
I don't entirely agree with your estimation, but I'd like to add one important point in favor of SVN: Many people in the industry are comfortable with SVN but don't know enough Git to work comfortably with it. If your whole team is used to SVN, then switching to Git might come at quite a cost. (The opposite can also be true, of course). –  Joachim Sauer Sep 3 '12 at 5:44
7  
I would upvote this dozen of times if I could. Many people go with the fad, but don't really think why would they need distributed source control. –  Euphoric Sep 3 '12 at 5:45
21  
@Euphoric: I know precisely why I always want distributed source control on every project. It has the important side-effect of making branching and merging simple, obvious and reliable. Subversion is still bogged down in corner cases with branching because the basic model it chose simply makes it more complicated. –  Jan Hudec Sep 3 '12 at 7:53
18  
Distributed version control is not a "fad". It is an evolution of source control, just like concurrent version control was an evolution over the file-locking paradigm. –  JesperE Sep 3 '12 at 8:29
5  
@MichaelBorgwardt, I actually did it a number of times. It is much easier than with subversion, the fact that everything is local helps a lot, there is no need to explain the "client" and "server" interaction. Workflow in git or hg is much more natural and intuitive (if you stay away from the tricky bits like history editing). –  SK-logic Sep 3 '12 at 8:52

"If you have a task that can be done on six hours, it is better to write a tool that does it in 20 minutes, even when creating the tool takes six hours?"

Distributed Version control is a different beast to tackle. It requires substantial learning for each developer. If you have the buffer to accommodate the learning process for each developer, you should move to a good distributed version control system. Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.

Distributed Version Control seems to be an eventuality. It is here to stay for a very long time, it is better that we adapt to it sooner than later. I remember the same discussion when SVN was new and people were used to CVS, lots of arguments were given for not using SVN, but eventually SVN became the most popular version control system.

If the company is well established with a lot of source code in the existing version control system, moving to a new system is a big task, but if the company is small or starting up, moving to a new version control is very easy. But if you stick to an older version control (in a new setup) you will hit the bottleneck somewhere in future where you will have to eventually plan a version control migration anyway.

I have seen a lot of pro SVN comments, but all of them tend to be of the nature "SVN is not bad" rather than "SVN is better". So I would strongly recommend that you choose a Distributed Version Control (such as Git) for your project.

EDIT Advantages of GIT over SVN

  1. No dedicated server required Actually, both can be used w/o a server.
  2. Can continue development even without a network connection.
  3. Branch management is much easier.
  4. Better support from CI tools such as Bamboo

Someone mentioned tooling (for visual studio) as a reason to stick to SVN. http://gitscc.codeplex.com/ provides GIT support for Visual Studio.

share|improve this answer
6  
SVN does handle binary files better then Git or Hg. –  Fake Name Sep 3 '12 at 7:42
2  
"You will hit the bottleneck somewhere in future where you will have to eventually plan a version control migration..." Sorry, I can't agree this is a good reason to make the move today. I've worked on many projects where this approach leads to making things more complicated than they need to be and the project is cancelled long before it ever gets to take advantage of those future benefits. Sometimes good enough, is good enough. Stick to YAGNI and take what does the job today. There'll be time enough for worrying about migrations later. At least you'll still have a project. –  njr101 Sep 3 '12 at 7:48
2  
Once the learning phase is over Distributed Version Control is much better than Centralized Version Control. I completely disagree with this. It may have some perceived benefits in some circumstances, but something as simple as the version number in svn being human-readable is a massive benefit in many organisations. –  TZHX Sep 3 '12 at 7:57
1  
@apeirogon - It all comes down to what you're going to put in the repository. The HEAD alone of one of the main repositories I work with is 11.1 GB! If I had it in a Git/bzr/hg repo, it would probably take up 100+ GB. –  Fake Name Sep 3 '12 at 8:13
1  
Of course, this is because this particular repo is full of PCB files and 3D models, which are all binary in format, and not very space efficient. The recommendation here (Electronics.SE, e.g. for people storing PCB ddesign files, etc) is very different then if it's for someone storing source-code. –  Fake Name Sep 3 '12 at 8:15

Client tooling hasn't been mentioned yet. You can certainly do everything with a command line script but having GUI integration can be a real productivity boost.

We work mostly with Visual Studio; integration into the IDE is definitely better with SVN than with Git right now. This may change in the future, but I'd certainly weigh this into your decision just as much as the version control functions.

Just like everything else, a version control system isn't a goal in itself, just a tool to get you where you're going. Pick the one that's going to get you there fastest based on your situation.

share|improve this answer
    
This is good point. I think one of the reasons why people preffer Git over SVN is that Git has better CLI tooling. But this can be offset with good 3rd party SVN GUI, like TortoiseSVN on Windows. –  Euphoric Sep 3 '12 at 7:41
2  
This is one of the reasons we went for Mercurial (and TortoiseHg) over Git. The advantages of distributed version control and decent tooling and IDE integration. –  HappyCat Sep 3 '12 at 11:03

I'm a Git fan. Recently I had to admit that one of the downsides of Git is that it identifies versions with hashes as opposite to svn's release numbers. The release number can be easier passed on by phone or something like that.

And that's the only pro I can imagine. If you really want to rely on that feature you can have it in a distributed and/or centralized VCS Bazaar. In Git there are tags that can serve the purpose.

Anyway I just couldn't imagine developing without quick branch switching, and stashing. These two features alone beat SVN, where as far I remember the same task required creating and checking out a whole tree into separate directories to achieve the same goal.

Those so called "advanced features of distributed version control" come with the time, and you don't have to learn them at the very beginning. Don't be scared of them. They are here to help you, not to get in the way. And there's no problem to set up a central repository for a DVCS.

share|improve this answer
1  
This is actually moot, git only needs a large enough part of the hash to be able to disambiguate, usually something ~ 6 chars is enough, not the whole hash. –  TC1 Sep 3 '12 at 8:30
1  
In practise, you never pass the git hash around. You can use any unique prefix of the hash, which typically is 6-7 characters. –  JesperE Sep 3 '12 at 8:32
1  
@JesperE: Yes, but SVN release numbers increase sequentially over time, while Git's hashes, even if you abbreviate them, might as well be random. –  Keith Thompson Sep 4 '12 at 2:53

would there be any specific reason to use Subversion those days

Apart from tooling support in IDEs (which I don’t use) – not really, no. Of course SVN may be more familiar but that’s about the only reason, and I’ve found both Hg and Git very easy (and very fast) to learn.

Yes, there are all those complex guides out there which describe how Git is trivial once you understand that branches are just homeomorphic endofunctors mapping submanifolds of a Hilbert space.1

I don’t understand that. But you know what? It doesn’t matter. You don’t need to know any of that stuff to use Git.

For the most part, Git and Hg are easy to use and they have definitive advantages over SVN. The elephant in the room is of course branching: branches just work in Git and Hg. By contrast, in SVN they are painful at best and broken at worst (merging multiple heads).

Of course you can still use SVN. You can also still use Windows XP. However, the majority of users who have tried both agree that one of the alternatives is vastly superior.


1 Yes I get that this is a joke. I think.

share|improve this answer
    
A Git tutorial with homeomorphic endofunctors mapping submanifolds of a Hilbert space? I need to read that! But doesn't this rather apply to Darcs, which is written in Haskell (which I reckon endofunctor refers to) and inspired by quantum mechanics (hence Hilbert space)? I really can't see what Git and HG have to do with these things. –  leftaroundabout Sep 3 '12 at 18:58
    
@leftaroundabout It’s a joke. The description isn’t even accurate (as far as I know). It’s a riff on the many tutorials which start with “git branches are easy once you realise that …” and then there’s a complex domain-specific metaphor after it. –  Konrad Rudolph Sep 3 '12 at 21:50
1  
Have you ever considered that all those overly-complicated tutorials exist for a reason? And what's it for anyway? I've never understood the obsession the DVCS crowd has with branching and then re-integrating a branch for every little thing. That's always felt to me like a solution in search of a problem. Re-integrating a branch in SVN is difficult because that's a really dumb and conceptually wrong thing to do in the first place, and I really don't find any argument that boils down to "our product makes doing the wrong thing soooo much easier" very persuasive. –  Mason Wheeler Sep 4 '12 at 3:08
1  
As for working on multiple changes in parallel, I'll admit that's a bit painful, but the right solution there is shelving, which is planned for the next SVN release. And most of the time, if you're working on multiple changes at the same time, (and especially if you're doing it consistently!) that's evidence of a wider problem which should be addressed at the organization level, not enabled with new tools. (See above, re "our product makes doing the wrong thing soooo much easier," and Joel's classic article on human task switching.) –  Mason Wheeler Sep 4 '12 at 13:01
3  
@KonradRudolph Merging branches back into the trunk works just fine in the latest versions of SVN. It's been getting steadily better for several years to where it's very good now. –  Adam Bruss Sep 21 '12 at 16:11

With SVN you can easily checkout parts of a repository down to the folder level, whereas with git, you get the whole repository, including all the history.

Depending on the situation this may have some advantages for SVN

(this also has some big drawbacks such as the hidden ".svn" garbage all the way up your folder tree).

share|improve this answer
2  
note: no .svn garbage since v1.7 - its now all stored in a single location. –  gbjbaanb Apr 10 '13 at 9:35

Not the answer you're looking for? Browse other questions tagged or ask your own question.