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.
Allow the version control system to be pluggable. Allow someone to use the built-in VCS, SVN, Git, Mercurial, etc with TFS.
I know many people who LOVE what TFS can do but HATE the source control. I have no problem with the source control but I think you’d see adoption skyrocket!
Yes, yes, yes, yes!
I am so happy!
And it is not just DVCS, it is the best one on the market. Microsoft adopted Git!
Justin Chase commented
Diego B. Fernandez commented
Hope it will fill my need for versioning + ALM
Paul Knopf commented
Un... *******.. believable!! Dream come true!
This is a suggestion to TFS, not to Visual Studio, so I'm not suggesting using plugins on VS, but for TFS to support DVCS.
Git-TF is a good start, but the server is still a central one. This has imposes several restrictions on what we can do. We need real DVCS support from the server.
Edwin Ashdown commented
Do you mean an integration internally or the ability to utilise plugins for other DVCS systems ?
I think git-tf is a start but with the capabilities in customisation of tfs it could be alot better.
I have written for my own usage a plugin for Visualstudio and TFS 2010/2012 that allows me to pull any changeset from GitHub, Bitbucket, CodePlex and tfs.visualstudio.com.
It can use Mercurial, Git, SVN orTFS as a repository source and it allows me to create Continuous Integration for the source code that gets pulled down.
Working on Continuous Deployment using the same process as well.
The suggested feature is to add DVCS support to TFS, not to Visual Studio. I don't really care about VS support, I use git or mecurial on the command line, and yes, there are several tools that do this already.
Simon Tewsi commented
Not sure what the problem is. I haven't used Mercurial, Bazaar or Darcs so I don't know how easy it is to integrate them into Visual Studio. However, Git already has excellent integration with Visual Studio.
Git Extensions (the excellent UI that sits on top of Git for Windows) integrates into Visual Studio already. It adds a toolbar, a menu and a couple of items to the Solution Explorer context menu if you select Visual Studio integration as an option during installation. Admittedly, I haven't tried it with VS2012, only 2010, but it advertises that it works with 2012.
For further Git integration you can use the Git Source Control Provider, available on Codeplex ( http://gitscc.codeplex.com/ ). This adds a much more fully-featured context menu to the Solution Explorer. Although I've got it installed I hardly ever bother with it, however, and only find it useful as it adds icons to the files in the Solutions Explorer (the familiar padlock for committed files, the familiar tick for files with unstaged changes and a new "i" icon for files that have been staged to the index).
I've never tried SVN or another of the popular centralized version control systems, apart from Source Safe and TFS. Does Visual Studio integrate with SVN out of the box? I assume there would be some Source Control Provider that would need to be installed. If so, how does this differ from the situation with Git?
Paul Knopf commented
I highly doubt this will ever be done, nor should it. TFS is largely a "single point of truth" source control system. I wouldn't use it for open source projects, but for company/internal projects, it is absolutely great. period. don't change anything!
Last time I checked, Xcode and MonoDevelop and a few other IDEs had native support for Subversion, Git, Mercurial and whatever else.
I guess I'm spoiled using Subversion at work, because AnkhSVN is pretty solid. But I do some work with projects on GitHub (thus git) and I choose to leave the IDE and do things on the command line (which is a pretty big context switch) because Git plugins for VS aren't up to par with Ankh.
I feel most features in Visual Studio are fairly well thought out, developed and tested and I'd love to see native Git or Mercurial support in VS.
You can't vote anything down on uservoice. Only up. It is a voting system. And apparently people disagree with you, as this is the second most important feature for TFS currently on uservoice.
Kudos for democracy!
We need a way to vote this down. If I want a DVCS I will use one. I want a better TFS. There might be a few tricks TFS can learn from a DVCS but I dont see any value in changing the product.
Matthew, I saw the git-TF. Good job, BTW.
And I continue to look forward to a full DVCS in TFS.
Matthew Mitrik commented
Something worth calling out here is the Git-TF project that we just released to enable cross-platform integration between local Git repos and TFS: http://blogs.msdn.com/b/bharry/archive/2012/08/13/announcing-git-integration-with-tfs.aspx
I know that this doesn't fully address the DVCS features discussed here, but it does enable some decentralization for developers that would like or need to use Git, and already have TFS in place as an ALM solution.
Michael Paterson commented
@Derek That's the idea. As with a lot of software systems there are interfaces, adapters, etc in the public API. I don't think it would be such a big deal to expose a few interfaces to do this. That being said, I also don't think it would be a huge deal for some pieces of functionality to not be implemented across every SCM system. If Git doesn't have an answer to the shelving analogy then simply return false or something.
Hossein Aarabi commented
You can use git-tfs to implement DVCS in your environment. TFS would be your central source control repository, while git would be your DVCS. The product does work well. But, I still think it would be nice if TFS enabled this option out of the box :)
Jesse Houwing commented
If not a full DVCS, I'd love it if it were possible to take my solution offline into a local "TFS Basic instance" with just Source control and read only work items. Then upon return I'd like to be able to commit my changes to the central TFS either by "Latest local version" all at once or by changeset.
It'd be even better if I could pre-associate my work items with my local changsets.
I wouldn't need to be able to take an editable work item store offline, but I'd love to be able to query the work items without the need to be connected to the central TFS.
Same also applies to the new review feature, currently you can't perform a review while offline, nor can you request a review while offline.
I am not arguing anymore... I know that it is possible to enable this. And time will prove me right.
Derek Licciardi commented
The problem with all of the pluggable version control system ideas was mentioned by one comment in this thread. TFS != Version Control alone. TFS' work item to code traceability is one of its largest strengths. Replacing the version control system is not as easy as it sounds when viewed under that light. Will git build in all the necessary touch points so that changesets can shelvesets can be tracked alongside work items? Will Perforce do this? What about SVN, CVS, Mercurial and Plastic SCM? TFS appeals to our highly regulated company mainly because of the traceability provided out of the box. Work item through to line of code changed. Work under Sarbanes Oxley or HIPPA regulations and you'll see where I and the other guy commenting on work item tracking are coming from. The source control choice isn't simply a geeks prefer to use this choice; it has larger implications for the company as a whole.