Enable distributed source control (DVCS)
DVCSs are faster on commit, enable multiple central servers, enable an excellent approach for branching, allow for offline work, and usually come with a better merging system. It also enables us to shared code without having to go through TFS, so I could push and pull changes with my colleagues directly.
Please enable us to work decentralized.
Some ideas for later:
I would not worry with integration with Work Items on the first version, and on a later version you can add the integration via caches. Build should be done on push, not on commit.
On a later version you might enable to push from one TFS repository to another directly.
Giovanni Bassi
shared this idea
Committed! http://aka.ms/gitinitvs
50 comments
-
James McKay
commented
+1 for making the source control element of TFS pluggable. That would be a quick win -- if I could use TFS for work item tracking, builds etc, and Mercurial for source control, I'd be delighted. Modern DVCSs have a lot of very powerful and innovative features in addition to distribution and easy branching/merging -- patch queues, hunk selection, and bisect, to name but a few.
I’m not sure that evolving the current source control tool in TFS in the distributed direction is the best way to go, however, since the two are based on fundamentally different architectures with completely different capabilities. TFS, like Subversion, is based on a linear history that puts branches into a separate folder within your repository, whereas the Git/Mercurial approach is to put them directly into your project history in a DAG (directed acyclic graph). The DAG is really the “secret sauce” that makes branching and merging so much easier in DVCS: it enables lightweight, anonymous branches, switching in-place to any version of your code on any branch, and easy, intuitive merging that doesn’t suffer from baseless merges. My fear with attempting to evolve from one to the other is that we might end up with something that either misses the point of DVCS entirely, or takes far too long to get there, or results in masses of unnecessary complexity and with it, fragility.
I personally think that the best approach would be something along the lines of what SourceGear has done, i.e. produce a completely new, distributed tool as an alternative to their centralised one. This would have the added advantage of losing the baggage of twenty years of legacy architectural and design decisions.
-
ScottWeinstein commented
Rather than try to rebuild a DVCS, perhaps have the version control aspect of TFS be a plugin, this way git, hg, svn could be used
-
Antonacci Enrico
commented
Excellent idea....
-
Giovanni Bassi
commented
Alfred, it is on the roadmap, but we don't know for when. We should vote to get this up on their priorities.
-
Alfred Gary Myers Junior commented
It looks like BHarry decided to attend your wish even before you asked for it http://blogs.msdn.com/b/bharry/archive/2011/08/02/version-control-model-enhancements-in-tfs-11.aspx
-
Vinícius Hana Scardazzi
commented
I second that.
Only one thing I'd like to mention is that, if integration with work items is a must, then work items could be integrated with pushes, not commits, just like the builds should be. Not sure if it's possible but it might be worth considering.
-
Neno
commented
Can you elaborate what benefits this would give the users?
-
Bryan commented
I wouldn't pick a DVCS specifically - but allow it to be pluggable - I personally am very comfortable with the TFS VCS, but Git and Hg have large followings and adopting TFS for all of the other goodness would be great without having to change over the Source Control System for an organization
