This is neither a Holy War invocation nor is it https://stackoverflow.com/questions/661389/tfs-vs-svn - This question is much more specific and would potentially make a team of developers very happy:

I used an earlier version of TFS for two years but I have not used it for years. What advantages does it have over Tortoise SVN? For example, does the merging work seemlessly or does it involve a lot of manual work; and does the shelving actually work (we could not get it working)?

The Platform is Windows (does TFS run on anything else) and the intended use is version control through Visual Studio 2008 / 2010 with the scope for Continuous Integration on x86 or 64bit build servers (depending on the product).

There would any ever be one develop stream per product. Projects would typically last less than two weeks (large pieces of work would be broken down into these discrete chunks of this size). The maximum team size to work simultaneously on a product would be less than six developers. Checkins on a branch would occur at any time (only explicit rule is that it builds). Merges back into the trunk (head) occur after project completion.

Running a TFS trial is likely to be costly to a business. Therefore, I have asked the question on here. I want to hear answers from those who already know (as well as those who anticipate pitfalls). There is no point reinventing the wheel. It makes no sense to incur unnecessarly research costs.

To reiterate: my major concern is merging. I know SVN Tortoise works (it has a few quirks around ASP.Net .csproj files but I can live with that) but TFS is supposed to have a great deal of features. I want the best deal for the devs.

  • 4
    I can guarantee you that TFS also has quirks around .csproj files, trying to merge in situations when multiple developers have added files to the project at the same time. – Carson63000 Mar 22 '11 at 9:35
  • I am unsure if the issue I am thinking about is related to Visual Studio rather than SVN. – CarneyCode Mar 26 '11 at 22:24
  • I posted about it here: stackoverflow.com/questions/2468852/… – CarneyCode Mar 27 '11 at 12:42
  • 1
    Seamless merging with Subversion? :-) – Htbaa Mar 29 '11 at 13:07
  • Seamless merging except for the quirks I mentioned :) I suspect you want to contest test. C'mon post your story here :) – CarneyCode Mar 29 '11 at 21:59

Both will do what you need. At my last job we started with SVN and moved to TFS later. Our team consisted of 8 developers and 3 QAs.

TFS was nice b/c it had built in VS support, built in ticket tracking, and you could lock files. We also used the SharePoint to keep track of all the documents and meeting notes for each project. It was a very nice and integrated....but it was also bloody expensive.

SVN was fine for our purposes though. That with a wiki and Jira and we were good. The only reason why we changed was b/c management decided we needed to be a Microsoft Shop.

I would say it's a nice tool if you can justify the cost and overhead. If not, you can't go wrong with SVN.

  • So, the movement to TFS was more political; rather than it's in-built ticket tracking? – CarneyCode Mar 27 '11 at 12:48
  • 5
    @Carnotaurus - Pretty much, ya. TFS had a lot of extra candy and it seemed very polished, but we didn't need it. We were using SVN, Jira and a Wiki to do everything TFS did. – Tyanna Mar 28 '11 at 13:37
  • I'll upvote you for an honest answer. Don't forget, you can find me moaning elsewhere: stackoverflow.com/questions/5448574/… – CarneyCode Mar 29 '11 at 22:09
  • Redmine and AnkhSVN - solves the lack of features you like with SVN, but much cheaper (and better - sharepoint, ughhh). – gbjbaanb May 14 '14 at 12:43

If you want the best deal for the developers, get modern.

I use svn and mercurial daily.

  • svn: because llvm/clang use it and I am following the project
  • mercurial: at work ;)

I can't say how much I can hate svn, really... once you've tasted distributed version control system and (notably) local commits, going back is like a slap in the face.

I cannot compare mercurial vs git, for I have not used git.

  • I have not used Mercurial, but I have used git and I regularly curse the decision that my company would use svn. – Peter Taylor Mar 22 '11 at 21:10
  • Ok, what's so good about Mercurial and why should we use it? – CarneyCode Mar 27 '11 at 12:46
  • @Carnotaurus: in svn, the code is the property of the server, with Mercurial, it's yours. You can commit locally, without connexion to the server, you can exchange commits with co-workers / friends, without a server. It's awesome. And you don't even to worry about backuping the server, since everyone's got a local copy of the history anyway. It's like going from a mainframe to cloud computing. Just try it (either Mercurial or git), and see for yourself. Once you've passed the month or two it takes to adapt, you won't be going back. – Matthieu M. Mar 27 '11 at 13:07
  • I'm really intrigued now. The problem is if it messes up then I bet I would receive little support. – CarneyCode Mar 27 '11 at 16:54

I use Tortoise for personal projects at home and TFS at work. Tortoise SVN is nice, but I have to say that TFS is pretty idiot proof. IDE integration makes it the best option when you have a bunch of developers on the project with mixed amounts of experience with source control. I say this because, trust me, you want the learning curve to be as shallow as possible. With an investment like this, all it can take is one weak link who accidentally deletes the project off the server, or screws up your branching all over the place, and you do not want that to happen. That being said, I love Tortoise for personal use or with a trusted team, TFS simply has a better GUI.

  • 5
    TFS idiot proof? Our (former) svn guys still complain about how complicated their usual workflow now is. – mbx May 13 '11 at 19:23
  • 2
    If you let someone actually touch some source code, I bet you can also be confident he'll get his way to correctly use a version control system, because that's generally an order of magnitude less complicated. – Johan Boulé Jul 23 '12 at 21:02

What you describe seems perfectly achievable with SVN. I don't know much about TFS so I cannot make comments on that part. But I think two other important questions are: Does management care what you use and what is the standard software to use for version control in your company? On the other side what would the developers like to use? Do they know TFS or SVN?

In my opinion it is better to have a slightly less advanced tool that developers like and use than to have a fancy tool no one uses. Here most of the work is still done in SourceSafe as long as people are happy with it I see no problem. (as a sidenote we are getting people enthousiatic over SVN here :) )

  • Management care only about the price and delivery times - We had massive issues with SourceSafe, particularly with merging. It is not an option. – CarneyCode Mar 27 '11 at 12:46
  • 2
    VSS to SVN is like going from hell to heaven. Switch ASAP. – DevSolo Mar 29 '11 at 15:22
  • I've used VSS, TFS (earlier versions), and now Tortoise SVN. VSS is not much better appears to have no merging tools. We used to use WinMerge. I warm to VSS as a lamp post does to a dog. – CarneyCode Mar 29 '11 at 22:06

I use TFS, SVN and Mercurial on a daily basis. At the moment, TFS is just being used for source control/bug tracking.

Mercurial has completely changed the way I use source control. Every time I make a change I can commit. Suppose I need to implement feature which requires the modification of three methods and the addition of two. My workflow goes like this:

  • Change method 1;
  • Commit;
  • Change method 2;
  • Commit;
  • Change method 3;
  • Commit;
  • Add method 4;
  • Commit;
  • Add method 5;
  • Commit;
  • Push.

In SVN, it goes like this:

  • Change method 1;
  • Change method 2;
  • Change method 3;
  • Add method 4;
  • Add method 5;
  • Commit.

If I make a mistake somewhere between changing method 3 and adding method 4 I'm stuck - I've got no way to revert other than doing some kind of manual diffing between the last commit and my current code state. With Mercurial, it's easy to see what I've done wrong as I have a more recent commit. I can't follow the Mercurial workflow with SVN because if I do I break the build. Mercurial commits locally so that isn't an issue.

As for TFS, I loathe it. Its backwards, slow, bloated and ugly. It may do some great things with continuous integration, but purely as a source control system it sucks.

In summary:

  • Mercurial will change your life for the better.
  • SVN is still a good option, especially if you're already using it.
  • TFS will try to kill you in your sleep.
  • this is the usual workflow for any local rcs I know – mbx May 13 '11 at 19:25

I don't know a lot about Tortoise SVN, but I can tell you that the merging in TFS is pretty seamless, and that the shelving definitely works! I use the shelving any time I have to leave for the day and am not in a position to check in. The Continuous Integration (CI) is also pretty decent. Plus there are a ton of other features for a larger enterprise.


If you ever plan to develop non-Windows solution, dump it.

It does have issues with existing Linux (and variants: eCos, uClinux, etc.) based solutions.

  1. Linux supports come characters in the filenames (like “|”, “:”, etc.) which are NOT supported by Windows. The TFS server rejects these files when attempting to add them.
  2. Instead of comparing the local file to the repository file to determine if a file has “changed” (like most other VCS), it changes the file permission on the client side to cue the client tools which files to check in. File permissions in Linux mean different things than Windows and this is bad for the Linux solutions.
  3. TFS interacts quite well with Microsoft development tools but poorly works with plugins, is absent for most tools and ultimately requires a Windows client tool to interact with TFS, which is not available in many cases.

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