I suggest you ...

Add Mercurial support to Team Foundation Server

The addition of Git support to TFS is really good news for us DVCS aficionados. However, while many teams are satisfied with it, many others find it a very contentious option due to its fairly steep learning curve, unintuitive behaviour, and at times confusing terminology.

For teams that are making their first steps into distributed version control, Mercurial may be a better option. It would be great if TFS could support both systems.

2,712 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    James McKayJames McKay shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    declined  ·  Visual Studio teamAdminVisual Studio team (Product Team, Microsoft) responded  · 

    Thanks for the feedback about adding Mercurial as a source control option for TFS.

    At this time, we are not planning to add support for any additional version control systems to TFS. The addition of Git to TFS provides teams with the option of the preeminent distributed version control system or the existing centralized version control system, TFVC. For developers that are specifically looking for Mercurial support, one option is to use the Hg-Git plugin that aims to losslessly convert Git commits coming from a Git server to Mercurial changesets.

    Matt Mitrik
    TFS Program Manager

    41 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Uygar YilmazUygar Yilmaz commented  ·   ·  Flag as inappropriate

        The sheer numbers of Git users is more than Mercurial users, that's for sure. However, there are more than that to consider here...
        First of all, when we're talking about companies or individuals that actually use the Microsoft stack, whether we're talking about the server stack, the development environments, or merely the .NET framework, Mercurial usage is wider than Git usage. That's not just caused by the more graceful learning curve thanks to the easier and more intuitive CLI Mercurial has, but also the Mercurial UI tools being out there earlier with much more maturity, the more consistent performance graph compared to Git, and the richer plugin ecosystem due to Mercurial's cleaner plugin API.
        Please don't get me wrong... I have nothing against Git's powerful CLI, nor do I have any objections against the postulates it was based on while it was still under design phase. I'm merely pointing out the fact that Mercurial has a wider user base within developers or companies using the Microsoft stack.
        Now, I also understand the licensing constraints Microsoft might face in order to implement Mercurial within TFS, but to be honest, they wouldn't cause that big of a headache for a company the size of Microsoft.

      • James McKayJames McKay commented  ·   ·  Flag as inappropriate

        Unfortunately, I think we're going to have to concede this one.

        The fact of the matter is that Git is now to all intents and purposes the industry standard for source control. Pretty much every new product and service coming onto the market with a use case for VCS integration makes it the preferred option, and many of them make it the only option.

        As far as usage figures are concerned, you can get a good feel for these from job aggregation websites such as itjobswatch.co.uk, indeed.com or dice.com. The figures from itjobswatch.co.uk and indeed.com now put Git in the leading position, just ahead of Subversion, and suggest that Git users outnumber Mercurial users by about ten to one.

        My main concern about Git was specifically that its steeper learning curve might be slowing down DVCS adoption, especially among teams dominated by "5:01" developers. However, for a professional software developer, not knowing how to use Git is rapidly becoming inexcusable, so that is something of a moot point these days.

        In the end of the day though, whether we use Git or Mercurial doesn't really matter all that much. The important thing is to have a user interface that is easy and intuitive to use while at the same time offering a rich DVCS experience and promoting good practices. There’s a lot of room for improvement there—we need to see full support for features such as annotate, bisect, the staging area, interactive rebase, stash, a graphical view of your branches alongside your source history, and better support for popular DVCS workflows such as pull requests, commander/lieutenant, and so on.

      • John JefferiesJohn Jefferies commented  ·   ·  Flag as inappropriate

        Disappointing indeed! It seems just obvious that Mercurial remains a very popular VCS that should be supported by virtue of the number of votes.

        I'm not sure how it was established that git is the "preeminent distributed version control system". It may well be that git is more widely used in the FOSS world, but as has been said many times, Mercurial is widely used in the corporate world by a far less vocal population. To the TFS Program Manager, guess which community it is that indirectly pays your salary? [Hint, it isn't FOSS].

        I'm not sure how to take the advice from the TFS Program Manager to use Mecurial via hg-git. It could be a joke, in poor taste. Or he could be seriously suggesting that we open ourselves up to a world of pain by relying on a non-standard extension. I use hg-git, it's a fine piece of work; but it isn't necessarily easy to establish the correct version to use for which version of the Mercurial *and* git combination. We can normally assume that hg-git will work with the latest versions of both; any other combination is anyone's guess. Ensuring that everyone in a workplace have the correct version of everything working together is too much to bear thinking about, even without adding the required Dulwich package into the mix. [Of course, not intended as criticism of the hg-git team.]

      • Yuri TrukhinYuri Trukhin commented  ·   ·  Flag as inappropriate

        Agreed with Anton Arhipov, Mercurial is very promising version control system (and Facebook understand it)

      • Angel EzquerraAngel Ezquerra commented  ·   ·  Flag as inappropriate

        I agree with Thierry PROST. What is the point of this uservoice site if a feature request with almost 3000 votes is rejected?

        I doubt I will ever bother voting again :-/

      • Thierry PROSTThierry PROST commented  ·   ·  Flag as inappropriate

        What's the goal of uservoice when 2,700+ votes are present and feature declined ?

        Very disapointed too ...

      • vv commented  ·   ·  Flag as inappropriate

        Git doesn't work very well on Windows - I guess Microsoft want us all to switch to Linux :)

      • Terry LTerry L commented  ·   ·  Flag as inappropriate

        @Matt:

        Very disappointing!

        This couldn't be a difficult feature to add, as you already have support (as you mention) for the "preeminent distributed version control system", and they are quite similar in many ways. Many of us have huge investments in Mercurial, and would find it quite difficult to switch our departmental culture from Hg to Git just for VS support.

        Plugins are great... but that means that Hg users quite likely don't get support in VS when a new version is released until the plugins catch up and stabilize. If I find this to be the case, it will only slow down my adoption of newer versions of VS.

        I understand you can't implement everything that every user wants... but this one seems like a no-brainer.

      • Thierry PROSTThierry PROST commented  ·   ·  Flag as inappropriate

        I agree, I also prefer hg instead of git, esecially for the patch queue feature (hg mq).

        Giving all my votes !

      • vv commented  ·   ·  Flag as inappropriate

        To clarify the last comment: hg is "safe" only by default. You can rewrite history if that's what you want to do, but the relevant extensions have to be enabled first.

      • Pedro J. MolinaPedro J. Molina commented  ·   ·  Flag as inappropriate

        @Michael-Paterson
        1. Hg is safe by default. It was constructed with this principle in mind: "The past cannot be changed." This has strongly implications on history tracking and auditing. Other DVCSs allow you to cheat with real risk of corrupting the repositories.
        2. Clean API easy to learn and remember vs (git API is organic)

        +Info to compare:
        http://www.wikivs.com/wiki/Git_vs_Mercurial
        http://blogs.atlassian.com/2012/03/git-vs-mercurial-why-git/
        http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/ (see a Sane Command Line Interface)

        Don't get me wrong: adding git support on VS was superb. I think hg deserve it also by its proper merits and community or users.

      • Konstantin MolchanovKonstantin Molchanov commented  ·   ·  Flag as inappropriate

        It's a matter of personal preference.

        I've tried both, and find Mercurial way better. Its syntax is cleaner and shorter, it generally just feels nicer to use.

        Having choice is good anyway.

      ← Previous 1 3

      Feedback and Knowledge Base