What advantages does TFS have over Tortoise SVN in this scenario?

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.

Answer 7

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.