In what ways is Mercurial better/worse than TFS? [closed]

Question

I've just joined a new company and at the moment we're using Microsoft SourceSafe as our repository. The settings aren't ideal and it's proving to be a big pain in the neck.

I've recently used Mercurial and thought it was amazing, so I'm advocating switching to that, but it looks like the company already has a Team Foundation Server licence and wants to use that instead.

Can anyone give me a list of points where one is better than the other? I've not used TFS and so I don't know what it's good/bad at.

Renwick

As a new employee I would not spend my time trying to get the team to change everything that suits my ways. Maybe spend a few months getting some things done, seeing how things work, building some trust and achieving some accomplishments. Given that you're asking here, sounds like you're not really suited to suggest this change. Also your question is leading and I think argumentative. – Mainis

@apphacker: I'm advocating it over SourceSafe (which everyone hates!), not over TFS (which I know nothing about). I just wanted to know the pros and cons of TFS versus Mercurial so I'd have a better idea of what life will be like once we switch to TFS (a decision has already been made and I'm not senior enough to change that). – Renwick

Answer 1

You cannot directly compare TFS and a DVCS.

If your company leans toward TFS, that may be because of the other features TFS comes with (data collection, reporting, and project tracking, all well integrated with Microsoft products)

---

On the pure Version-Control side, the Team Foundation Server 2010, with its Team Foundation Version Control (TFVC) 2010, introduces branches as first-class citizen.
See Team Foundation Server and branching characteristics, compared to others.

I still find their branching models more complex than a Mercurial or Git one.
See TFS2010 Branching into a subfolder of another branch vs. Guide to Branching Model in Mercurial (and this SO question which also details merges and branches with DVCS)

That being said, it remains a CVCS (Centralized VCS), meaning you get different working processes than with a DVCS: see Describe your workflow of using version control (VCS or DVCS).

The true killer feature of a DVCS remains its merge capability (simpler and faster than any CVCS). But introducing a DVCS in a corporate environment remains hard.

Faggoting

I'm interested in the version control side of TFS - what does it do well/badly? – Renwick

@Jackson: I have completed my answer on the VCS side of TFS. – Faggoting

TFS and DVCS are different. That's why codeplex added support for mercurial (2010) and later git (2012). Initially only TFS + SVN bridge is supported. – Mulder

TFS is more than source control. It is more integrated. TFS can compare to veracity, which integrates source control with wiki and bugtracker. – Mulder

Answer 2

I recommend Joel on Software http://hginit.com for a list of very good reasons to switch to distributed version control.

Gargantua

I agree that Hg Init is a nice tutorial that highlights many benefits with DVCS, though it's probably good to mention that the author has a direct economic interest in getting people to switch to Mercurial (or more precisely, Kiln (which I think is a great product, but that's not the point)). – Angilaangina

Answer 3

I have found a few gotchas with TFS that make it a little different than other CVCS.

• TFS is very difficult to use outside of Visual Studio. Even diffing versions is done inside VS. Personally I only like to use VS for writing code.
• We have had lots of issues with dll's and other binary files not updating to the latest version.
• TFS makes all your files under version control read-only. This makes modifying files outside of VS very painful. In fact, this is still causing issues with out Silverlight projects in our Continuous Integration build in TFS.
• The command line tool for TFS is not easy to use from the command line. (Personally, I like to use the command line)

Background: My company switched from SVN and TFS and I use Mercurial/Git for my side projects. I also followed this blog about using Mercurial with TFS and it has made my work with TFS much more enjoyable.

Saki

To touch on your points. 1).How can you use TFS for writing code? do you mean Visual Studio? 2). dll's should not be checked in, but built from source 3). TFS 2012 allows for local workspaces, so no more "rogue" local files 4). IMO command lines utils are in the same category as .bat files, which are merely opportunities for programmers to write wrappers over. – Unruh

1) Thanks, that was a typo. 2) dll's where for third party libs like nunit and nhibernate. 4) I currently use git from the command line and love it. I did wrap TFS command line in rake tasks and batch files so it was actually usable; however, it was very painful to setup. – Saki

Answer 4

TFS is an Application Lifecylce Management Tool not ONLY a source code repository / versioning system.

It's strength's are:

-It's natural integration into Visual Studio (+100)
-It's Full App Lifecycle support from Work Item through Q/A acceptance.
-It's integration with MS Project / Sharepoint, and all the other 
 hoo-ha's you get 
-And now TFS 2012 has added support for "Local Workspaces" which allows
  for off-line working, but also allows "Server Workspaces" which is 
  similiar to TFS 2010. 
-Diff on every Check-in / Commit

The Source control side of it is also very strong, however, personally, as long as I can see the entire history, not lose code, and not have my code "stepped on". I could give a darn.

I've been using TFS since 2008 and the latest round of improvement further demonstrates Microsofts commitments to evolving their products and keeping up with industry changes. Personally I love it, but i stay in the Microsoft environment (which i also love).. outside of that, it may not work with everyone's needs.

Now, a few days into working with Mercurial professionally (BitBucket / Mercurial / tortoiseHG / VisualHG ) , i have to say the tools seem a bit dated. The integration with Visual Studio is like luke warm coffee (ho-hum), and the explorer integration takes me back to "the good ol days" when i was lucky to NOT be working on Visual Source Safe.

Another thing to take note of is the ease in migrating from Visual Source Safe into TFS, it's fairly painless.. i recently moved my last companies entire history in VSS into TFS and it just took a couple command line utils and overnight to get all the change history moved over. I was shocked (as where my colleagues) at how easy the migration was, it even kept all the history since the beginning (by request of the powers that be)

I'm definitely biased having worked with MS tools for a long time, but there's not much to source control as long as it works..

If your organization wants to truly manage all aspects of application development, and they haven't got integrated tools or processes yet, TFS will afford them the ability to grow and manage from the get go.

Start with Source Control, end up with specs originated in MS Project, tied to work items tied to Unit Test tied to acceptance tests tied to automated builds and deployments

And Lastly: Burn Down / Velocity Charts

Unruh