In what ways is Mercurial better/worse than TFS? [closed]_问答_开发者

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. Closed 9 years ago.

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 T开发者_JAVA百科FS and so I don't know what it's good/bad at.

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.

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

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.

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