Everything you want to know about Visual Studio ALM and Farming
Brian Harry is a Microsoft Technical Fellow working as the Product Unit Manager for Team Foundation Server. Learn more about Brian.
More videos »
If you haven’t seen it, here’s the announcement:
http://blogs.msdn.com/codeplex/archive/2010/01/22/codeplex-now-supporting-native-mercurial.aspx
As you may know, CodePlex provides a hosted community development environment and has been built on TFS (you can connect to it from VS like any other TFS server). They’ve just recently announced support for Mercurial for version control and I’ve already seen several threads of the form “Does this mean Microsoft is abandoning TFS?”
If you read my blog, then you know I’m responsible for TFS. You may be interested to know that I was involved in making the decision to add Mercurial support to CodePlex. It does not, in any way, signal a move away from TFS or a lack of confidence in TFS. TFS is the core of Microsoft’s ALM solution and it will continue to be for as far as I can see into the future.
So why would we do this? Well, the biggest reason is demand for distributed version control for open source projects. By there very nature, open source projects lend themselves to distributed version control. I think many scenarios can benefit from it but open source really needs it based on the submission model that is often used. TFS doesn’t support distributed version control today, it makes sense for CodePlex so we chose to add Mercurial.
I fully expect that we will be adding distributed version control to TFS. In fact, in the next few months, I expect to kick off a prototyping effort to experiment with this. I’m not sure yet what our productization plan will be but I want to get started understanding the experience we want to create and the effort to do it.
So what about the “message” that this sends? I hope it sends the message that we listen to customers and we believe in choice. CodePlex still supports TFS and customers can choose which they want. The challenge I’ll be giving to my team is that I want most customers choosing TFS – even for open source development projects. We’re going to do that by making TFS a more desirable experience than Mercurial (or any other system available). Given open source is not the sweet spot of what we do today, don’t expect that to happen over night. It will be one of the stars that we chart our course by but we will continue to ensure that TFS is the best solution on the market for teams that need the power of a full, integrated ALM suite that addresses the needs of the diverse participants in the software development processes: Developers, Testers, Architects, Project managers, Business analysts, Business stake holders, IT management, Operations staff and more.
Brian
I for one am incredibly excited about this. Thanks Brian.
BRILLIANT! This is a great move
Fantastic! If you ever need a beta tester look me up :-)
Personally, I'd love distrubuted source control in TFS. But what I'd like *even more than icecream* would be a way to use TFS work item tracking and "plug in" some other SCM product (svn/git/mercurial/whatever). The work item tracking (and support for excel) in TFS is great. But the source control in TFS simply does NOT fit well for us. However, the people using work item tracking are also the people deciding what we use, so....
Yes please. Give us distributed source control in TFS!
For me I would settle for just a simple offline mode that would do versioning offline and merging in the all the changes made during offline.
With the number of developers using GIT, why the hell would Mercurial been chosen? Really stupid decision. It shows how "well Microsoft listens".
There's a lot that MS can sell for development tooling without going out and rewriting existing OSS. This waste of energy is a shame. Instead of working with the development community it has to have it's own.
I've steered all my clients clear of TFS in favour of GIT and OSS tooling. Amazing how many organizations easily swallow up all that inefficiency, friction and unnecessary costs.
The success or failure of a "distributed version control" feature largely will depend on what API is chosen to be supported. Choosing to support as an enhancement to the TFS protocol is likely to not win any friends. However putting a compatibility API between the world and TFS would be a huge step forward. Imagine walking into an IT shop as a new developer and having this exchange:
newguy: "where do you want me to check in my code?"
Senior Dev: "use server 192.168.0.98"
newguy: "Oh yeah? what type of server is it?"
Senior dev:"It's TFS."
newguy: "What's TFS?"
Senior dev: " I don't know, they were using it when I got here and it understands svn so I have just been using subclipse to checkin my code."
Senior dev2: "What?!? 0.98 is a Subversion system? I have been using my git client for 2 years, I thought it was a git repository."
That is real flexibility. TFS would quickly become the defacto standard because it is what anybody wants it to be.
How about adding diff/patch in GNU/POSIX format to the Visual Studio UI?
I'd personally rather see TFS adopt a distributed model instead of bringing on a separate tool. I'd argue that a distributed model is much better. The lack of this in TFS has caused issues on every team I've worked with. Sure, we can get around it, but TFS's server-centric model drives many pain-points. I hope this doesn't mean we (Microsoft) believes this is the one "true" model. I understand there are benefits in either case, but I know which I'd choose, if I had to. I was very sad to see TFS bring this ideal along from the SourceSafe days. I'll be very happy to see it abandoned -- or at least a built-in option to choose a distributed model, like SvnBridge currently enables.
Brian, it would be great if you could write a blog post explaining your view on distributed version control systems, just in general and its relation to TFS. I've read http://www.joelonsoftware.com/items/2010/03/17.html and http://hginit.com/, and to me it seems that maybe TFS internal structure is not even that different from a distributed version control system? I.e. changesets seem to be the core "entities" that TFS stores. Sure, there is just on repository and it is not distributed, but in a sense it looked to me as if TFS might be a lot closer to a distributed system than say SVN, at least from the internal data structure point of view.
I think such a blog post would be fantastic. I really enjoyed your post on TDD, and e.g. it would be fantastic to get your unique view on distributed version control. Do you think it is a hoax? Is TFS very similiar? Etc.
Also, Martin Fowler recently also raged against TFS and pro distributed version control, maybe you could address his points also a bit?
Ok, and actually, I am aware you have a product unit to run, still ;)
Great news, I hope it'll happen soon!
That said, I hope that the current state, in which CI is extremely easy to set up, won't change due to the distribution support.
Besides, we do have a lot of issues bothering us already, such as a way-too-weak client (seriously, deleting the local folder and preforming a Get Latest will lead to no files at the client machine and an "Everything's Up to date!" message - BAD).
Brian,
You mentioned that "In fact, in the next few months, I expect to kick off a prototyping effort to experiment with this." Is this prototype available somewhere for us to try out and see how it works? We're looking at moving from GIT to TFS but don't want to go to the heavy branches that TFS 2010 currently has. Anything available?
I don't have anything to share at this time. We have spent the last few months working hard on planning what our next release will have. It's looking like we won't be doing full DVCS this product cycle but we will be doing some stuff that will result in many of the benefits. We're just now starting to implement some of it and I suspect it will be a few more months before I have too much more to say about it.
I wish I could be more helpful,
Brian, it has been a few months... I'm currently sitting in a DVCS/Kiln presentation by Spolsky and company - arguments for DVCS are not bad. Any new news on TFS and DVCS?
Nothing we are talking about yet. I've said that improving the TFS version control experience is a high priority for us and that DVCS capabilities would be a direction we'll evolve. We're working hard on the next version and I think there's going to be some stuff in there people will like (but I'm also sure people will wish for more than we can deliver). We're not quite yet ready to start talking about the features of the next release though.