CODEWITHSUNDEEP
mercurial
Riz
Riz

Reputation: 6676

TFS 2012 version control vs Mercurial

I'm evaluating a version control system for our team (of 1 to 2 developers) and am wondering how TFS 2012 version control compares to Mercurial in terms of merging and branching. We don't have a large team and it might just be me and maybe another developer so we may not need robust branching/merging capabilities that a DVCS offers. I haven't been able to find much info on TFS 2012 version control in terms of its capabilities. Can anybody point me to a guide or highlight some features? Please note, that we only have access to standalone version of TFS 2012 on VS professional version.

Thanks

Upvotes: 9

Views: 2433

Answers (4)

jammycakes
jammycakes

Reputation: 5866

Mercurial branching differs from TFS in one critical way. Whereas TFS stores your branches in a different part of the filespace, Mercurial stores them in the history itself. This massively reduces the friction involved in branching and merging. It means, for example that:

  • Branches are created implicitly, simply by updating to a revision other than the latest, then committing on top of that.
  • Branches are also closed implicitly, again, simply by merging.
  • Branches can be re-opened implicitly, the same way as you create them in the first place.
  • Mercurial lets you switch between branches in-place very easily. You don't need to set up separate workspace mappings, and you don't need to change from one directory to another.
  • Branches can be anonymous.
  • Whereas TFS has "baseless merges" (which basically means it has massive problems with branches that aren't in a direct parent/child relationship), there is no such thing in Mercurial. It is always possible to find a common origin between two revisions, no matter how far apart their respective branches have diverged.
  • The graphical view of your branches in TortoiseHg is integrated with your project history, making it much easier to understand how branching and merging actually works in the first place.

There are several advantages of branching and merging which apply even to small teams or solo developers. One such example is being able to fix bugs on your production system even when you have other features in development. Another example is exploratory or experimental development: if one approach doesn't work out, you can easily roll back to the start and try a second, different approach, while still keeping the original approach around in case you need to refer back to it.

Upvotes: 7

Andrew Clear
Andrew Clear

Reputation: 8020

The previous "answers" are a little strange. Branching and merging in TFS 2012 works exactly like you would expect it to, with both a GUI and command line implementation. Here's a good document that covers the topic fairly completely:

ALM Ranger Guide updated

Upvotes: 2

gnz
gnz

Reputation: 394

If you are in a small team, go with Mercurial without a doubt.

Mercurial is lightweight and flexible with regards to the specific development workflow you will use. It fits smaller teams much better, in fact, it even fits a solo dev because it does not impose any administrative overhead.

About the need for merging, it's really not an advanced feature as you imply: it is a very fundamental feature that most (all?) non-distributed VCS just can't get right. You might not need it now, but if you ever do, you'll have it right there in Mercurial and it just works.

Upvotes: 0

Lazy Badger
Lazy Badger

Reputation: 97282

Preface:

I'm not related in any way with TFS and never used it

Face:

Newest 'tfs2012' question, at least some (How to set up TFS to cater multiple projects to multiple clients, TFS 2012: Correllating binaries to builds and source code, TFS 2012 Disable Multiple Check-out not working), demonstrate us problems, which I never consider even as question in Mercurial (with some added external tools sometimes). But you can understand also, that TFS positioned as full ALM-tool, not as pure SCM, which Mercurial is.

"Team Foundation Server is the Lotus Notes of version control tools" from James McKay is not freshest article (Feb 2011), but at least some statement are still valid, I think.

Amount of branching-merging will correlate to team-size only partially, mainly depends on the style of development, habits of developers

Upvotes: 0

Related Questions