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.
Никому Не commented
GIT- big heap of ****!
Mercurial is a more user friendly and useful (hello named branch!)
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. Molina commented
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://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 Molchanov commented
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.
Dennis Apter commented
@Michael Paterson it's works just out-of-box
Michael Paterson commented
@Pedro why do you prefer Mercurial? I have never used it.....
No doubt Mercurial is a better and more clear option.
Pedro J. Molina commented
+1 Mercurial rocks! I use it, and recommend it over Git for their tool support and much cleaner and less esoteric API.
rod boggess commented
I should mention that we already use Mercurial. Using Team Foundation Services is optional, and an option that will likely never be exercised unless and until it can integrate with Mercurial. So, a plus one from our whole team. Oh, well, you'll only let me vote for +3, and I doubt I can convince them to log in.
I don't have any issues learning Git, but providing developers a choice with regards to version control is a must. Mercurial still has better Windows support - this is pretty much a big reason why TFS should support this system.
Anton Gogolev commented
That would be great! While you're at it, I think I'd hint to a somewhat of an alternative: HgLab ( http://hglabhq.com ).
Chris Scott commented
> Recommend to close this, as it seems like Mecurial is losing market share to Git.
Hg may not have the mindshare that github brings, but it has lots of big FOSS projects (java, python, mozilla, openoffice) and a steadfast windows corporate adoption rate. The latter was mostly due to the early days of git where windows was a second-class platform.
There's a reason that FogCreek choose mercurial for Kiln. There's a reason that Atlassian bought BitBucket.
Lastly, the core concepts between git and mercurial are mostly the same. Adding support should be pretty straightforward to implement and maintain.
Julio César Rocha commented
Mercurial is also an important player in the SCM industry.
Is the Git provider open-source?
Many developers (including me) would be happy to implement the Mercurial provider knowing what APIs or interfaces to code against.
Mike Doerfler commented
I think you'll find a lot of non vocal developers/companies using Hg. You just hear more about Git.
James McKay commented
@professor: I'd suggest we assume good faith here. Many Git users feel the same way -- and as a Mercurial user it's easy to feel intimidated by it.
But I'll just explain why I've asked for Mercurial in the first place. Microsoft talks about three different personas of developers: “Mort”, “Elvis” and “Einstein.” Git has pretty much cornered the market for the “Elvises” and the “Einsteins,” but it is *actively hostile* to the “Morts.” I’m talking here about people such as corporate developers who switch out of code mode the minute they leave the office, and graphic designers who only got into web development because their boss told them to. People who aren’t on GitHub, still believe that Subversion is the state of the art, and view the command line as “hardcore.” These people are less visible online because they tend not to blog or go to conferences, but they hold sway in the overwhelming majority of workplaces.
Here's the deal. I firmly believe that the “Morts” in particular need to be convinced of the value of distributed version control. At present, however, they’re being confronted with the complexities of Git, find it blows way over the tops of their heads, and in many cases, they simply give up on it, tell us that distributed source control is way too complicated for them, and as a result, many of us DVCS users are still stuck with trunk-based development in Subversion.
That is why I maintain that the DVCS scene still needs an option with a gentle learning curve, familiar terminology, a first-class GUI and good documentation, that is relatively easy to get right and relatively difficult to get wrong.
Are you attempting to troll?
Recommend to close this, as it seems like Mecurial is losing market share to Git.
Lazar Sumar commented
I would like to add +1,000,000 votes for this but if that fails please count me as at least a +1.
Friedrich Kastner-Masilko commented
I can second that.
Our team uses Mercurial for Windows development exclusively, and given the current state of customization via extensions and familiarity with the TortoiseHg toolset, there is little chance that we will ever change to Git.
Hannes Kochniß commented
I would really appreciate it, my team uses Mercurial and out whole tooling infrastructure is setup around it. We would really benefit from TFS ALM, but switching from Mercurial is just too big of a step for us.