I’ve written about this before but it keeps coming back. From time to time I get the question “Is TFVC dead?” I guess I have to just keep answering it. No, it is not.
We added support for Git in TFS 2013 so that we’d support the best centralized version control system and the best dvcs in the industry. We’ve been investing heavily in Git because there’s a ton of work to do to bring it up to parity with what we can do with TFVC. I think people get confused for a number or reasons. We talk about our progress on Git a lot. The industry talks about Git a lot. And, if you are watching, you’ll hear more and more about teams inside Microsoft adopting Git. My own team has moved a bunch of stuff to Git. All of these are true and some people assume that they all indicate to TFVC being abandoned. They do not.
Most of our customers still use TFVC and we value this tremendously. Most people in Microsoft still use TFVC. Most new projects created today on VS Online choose TFVC. No doubt, in all of these we are seeing a shift where Git is growing share and I fully expect it will continue to grow. There may even come a time a few years down the road where Git passes the 50% mark – I don’t know but it’s possible. Regardless, we’ll still have hundreds of thousands, if not millions on TFVC. It will continue to be important to us for a long, long time.
That’s all just talk, show me some evidence.
The core TFVC engine is pretty darned mature. It’s used by super large teams and is incredibly reliable. Most of our focus in TFVC investment is “around the core”. Let me give you a ton of examples.
- We’ve done a bunch of work on our web version control UI – enabling things like in web editing, checkin, delete, etc. We’ve made that work for TFVC.
- We added support for “welcome pages” which basically are wiki pages. We made it work for TFVC.
- We’ve done work on CodeLens indicators for TFVC, including some that are only available for TFVC – like the “incoming changes” indicator.
- Build.Vnext supports TFVC
- We’re building a new code search experience. Though the private preview only supports Git, we will add TFVC support before it ships.
- We’re working on code review improvements, including things like support for iterative code reviews, a web experience, an improve VS experience with inline commenting, etc. All of this will work for TFVC too.
- We recently added support to Team Explorer Everywhere on Mac/Linux for longer than 260 character local paths in TFVC – a very common complaint.
- One of the biggest chunks of work in Team Project Rename has been in getting TFVC to fully support it. There have been some core changes in the engine to make this work.
- We’re working on support to have TFVC and Git in the same team project to enable better coexistence – that will require TFVC work.
There’s tons more I’m probably forgetting and some stuff I’m not ready to talk about yet. TFVC is not only not dead, we are continuing to invest heavily and will continue to. Choose what best fits your workflow and feel confident that we’ll keep bringing you forward.
I hope this helps address some of the concerns. Please let me know if there’s anything else I can do to help.
Brian
Those are some nice features. I've wanted something like Welcome pages for a while now.
Do you think you could add some more detail about which of those features will require a TFS server upgrade?
"including things like support for iterative code reviews"
Good news! I don't think I'd seen that mentioned before.
As an aside: Brian, I know you got pinged here about a problem with the Lumia 1020 which had absolutely nothing to do with you (not by me, as it happens), and you still followed it up and tried to get someone from the relevant team to communicate with us users about it. It seems that we have a fix for that now, and the relevant people are being MUCH more communicative. I just wanted to let you know that I for one really appreciate you getting involved. Thanks.
Thank you for news about TFVC.
What about fundamental improvements in TFVC?
I use TFVC more than 8 years in large projects (>100 devs). There are some areas that would like to improve in TFVC:
1) Merge improvements (use content specific, less rename conflicts, avoid backward empty merge, …)
2) Server side Check-in policy (cross palform, not depend of local dll's, easy update/deployment)
3) Branching improvements (split branch, rename without history, …)
4) Migration – user-frendly code migration from Git to TFVS and vice versa (including history).
All good but when a merge tool for sln and csproj? Every merge is a nightmare.
IMO, the lack of any changes to TFVC itself might spark the rumors. In TFS 2012 there were a few major improvements, Local Workspaces, the improvements to the merging to make resolving conflicts much much better than TFS 2010. These new changes are more around TFVC that inside it.
That said TFVC is pretty mature, and is the best CVS, but there are still some things that it could do a lot better – stackoverflow.com/…/how-do-i-avoid-having-to-merge-every-file-in-our-repository-after-a-baseless-mer 🙂
Oh, and I cannot wait for #9 "We're working on support to have TFVC and Git in the same team project to enable better coexistence – that will require TFVC work." – it will enable a migration path for larger TFVC Repos into smaller Git ones. Thank you!
When a company like GitHub only cares about 1 type of VC, then there is no such thing as "mature" … to them their product will never ever be mature and put in a state of "maintenance" which is what if feels like MS does with it's "mature" products..
Sometimes it's hard to be a Microsoft user when it constantly puts it's products into a "mature" state and then moves its dev teams onto other things …
p.s. this is why companies like mine have moved on from TSVC to GIT and using GitHub … similarly with using other open source products where we are sure they devote 100% of their resources to said products, and not spread the teams thin on whatever "new" techs they fancy!
Will there ever be an option to convert a TFVC repository to a Git repository including history, labels, branches, work items links, etc.? We would like to use Git for some projects but would don't want to start over.
Brian, sure sure it's not "dead" but let's be honest, TFVC is effectively DEAD by saying it's "mature" and from all indications Microsoft has put TFVC into "maintenance mode" and it's gathering mothballs.
If you truly are commited to TFVC…put your money where your mouth is and open source the TFVC code base.
Show us the # of developers making actual code changes weekly to the TFVC code base.
I bet it's less than a dozen developers and less than a 1000 lines of code a week.
I find it hilarious that the TFS developers…who write TFVC don't use their own product anymore for their daily commits..but instead use Github.
BTW, I've worked with TFVC, and TFVC is just broken.
For example labels have been broken since 2005 and no-one at MSFT wants to build a proper labeling feature for TFVC….oh no…use our heavy weight "branches" instead.
It's crazy that in 2015, it's still possible to accidentally overwrite labels if you type the same name as a previous label:
stackoverflow.com/…/how-do-i-prevent-tfs-from-overwriting-a-label
t's crazy that in 2015, it's still possible for somebody can come and edit a label, by including or excluding files from the label, or changing the versions of files included in the label. And there will be NO HISTORY of these changes to the label definition."
stackoverflow.com/…/tfs-build-get-source-code-by-label-issues
sure, sure keep putting up blog postings stating that TFVC is not dead…but let's be honest TFVC is not the future…and well hey lets be honest and actually admit that Microsoft isn't going to deliver ANY major feature development on TFVC…because…we'll it's mature…and the problems in the TFVC aren't really problems….no no those are "features".
See ya later…on Github….where real devs go to store their code.
I heard Silverlight is not dead, because the tools still support writing in it. And neither is VB6, because if you really want you can still write in that too.
Despite the move towards open-source, MS remains the absolute worst at being honest about the direction of their products. When MS shifts resources away from a given technology, it is destined to a long, painful death with MS insisting every step of the way that its still fully alive right up until the very last second when they tell you they're dropping all support.
Please just let it die and stop writing blog posts like this that let inept system admins point to an official post and claim the company should not switch to Git because 'TFVC is not dead'. What a great reason to keep using source control from the people who gave us VSS.
@John, I'll try. Most of these require an update to some version of the TFS server. This page is generally your best resource for determining what release things are in: http://www.visualstudio.com/…/release-archive-vso
Here's what I think the answers are:
#1 – ongoing. Some improvements in 2013.3, 2013.4, 2015
#2 – TFS 2015
#3 – I can't remember
#4 – TFS 2015
#5 – I don't know for sure yet, but probably TFS 2015.2
#6 – TFS 2015.1 or .2
#7 – No server changes
#8 – TFS 2015
#9 – TFS 2015.1 or .2
Brian
@Alexandr, Some of this I'll take as feedback. Here's some specific comments:
Server side checkin policies – That's what gated checkin is for. We've had that for a good long while now. You should write your validations as build tasks. With build.vnext, this kind of customization gets easier.
Migration – We have the git-tf tool. It was designed for interoperation but can also be used for migration.
Brian
@Fabio, That would be a good improvement that would apply to both TFVC and Git.
Brian
@Scott, I can't remember how much of that the git-tf tool handles. I'll poke someone.
Brian
I was going to comment yesterday, but decided to wait and see what form the comments from other posters would take.
I was not disappointed.
The general frustration with Microsoft's policies in regards to its products has been growing for some time with the only one seemingly unaware being Microsoft. The whole shift in focus to a device and services company, or whatever catch phrase you are using this week, has been implemented in true Microsoft form of carefully phrased announcements that, on the surface, seem to be trying to reassure customers that all the time and effort they have put into a Microsoft technology/product is not going to be wasted, while not actually committing to anything.
In short, Microsoft has lost the trust of its customer base by turning a blind eye to the impact of the drunkards walk they have taken over the last decade and how difficult they make it to stay current while maintaining a growing code base. News flash Microsoft, we have actual jobs to do and cannot spend all of our time going back and rewriting the same features over and over again just because you have decided to chase some new flavor of the month technology.
The current rush to push everyone into a subscription model via its cloud services has resulted in products that are less stable, less usable and in many other ways… less.
I am one of many long time, over 30 years in fact, Microsoft developers who loves implementing new technology. But it has to provide a clear value to my company and the argument that it is the latest and greatest is not a clear value. I am currently at the beginning of a project to redesign/rewrite a major subsystem that was originally written using VB / Windows Forms. This project is driven by a business need and not because Microsoft parked Windows Form development at the edge of their 'Mature Technology' cliff, but either way I must now choose a new language and UI framework. You would think it would be easy, well the language was as 'C#' is the only language that Microsoft seems to be fully supporting, but I want a framework that truly takes advantage of the underlying OS, and not a least common denominator web UI as maintainability and speed are important features, but I am left unsure if any of the Microsoft frameworks will still be supported by the time this project is completed.
Is there an Eastern Indian equivalent to the Chinese curse "may you live in interesting times", for some reason it would seem to be more relevant that way?
@Charles Ryan use XAML with Windows Universal Apps
"it keeps coming back." you are correct, the question keeps coming back, and WILL continue to come up every time a new project has to make a choice about the version control tooling to be selected for the project.
There aren't any new <substantial> features coming to TFVC so we have to look at other version control platforms and GIT just has so many more engineers contributing code fixes to that platform.
github.com/…/contributors
Brian, why can't the TFVC team deliver "merge by work item" for TFVC?
From all outside indications, it appears that the the TFVC code base is a giant convoluted mess that Microsoft's Senior Developer engineers can't even maintain, or even consider enhancingimproving.
"Merge by work item" has been a long, long requested feature that would be super useful and a valued improvement.
visualstudio.uservoice.com/…/2047315-merge-by-workitem
"Thanks for the feedback on this idea. We have reviewed this feedback and determined that we will not be able to complete this suggestion in the foreseeable future."
visualstudio.uservoice.com/…/2064345-merging-support-for-workitem-changes
"We have no plans to improve this experience by adding a diff experience in case of conflicts."
@CharlesRyan use Xamarin Forms (http://xamarin.com/forms) as you are going to have to, whether you like it or not, support iOS, Android, and Windows for any major application over the next decade.
@Chris Marisic
I would not create a Windows Store App at gun point, which is where I would probably end up if I tried to release this application as one, the UI is total garbage and the enterprise management tools are a sad joke.
@Oğuz
Perhaps if I was creating a simple consumer app, but this is a complex enterprise application that would not run on current generation ios or android devices.
Disclamer: I am one of the main developper of git-tfs (the other is a guy from github)!
@Alexandr & @Scott
I'm not sure that git-tf will help you a lot to migrate your history, except if you have only ONE branch. That's the only thing git-tf support 🙁
@Brian
I think that git-tf is a dead project with no commits in more than one year and just enought the basic features to commit and fetch to TFVC.
It's absolutely not a tool to migrate your history and I am as disapointed as @Alexandr & @Scott that Microsoft don't have a tool to migrate history.
I think that TFVC is not a very good Version control software that's why I end up using, and now developping, git-tfs to NEVER have to use TFVC anymore (and it's a shame because as a consultant all my customers use TFVC 🙁 ).
You tell that TFVC is a good and mature product, but my experience as a developper of git-tfs and the one that try to add a good branch support, TFVC and it's API is a hell! 🙁 TFVC permit all these strange (and bad) things that your history end up in a mess… impossible to migrate (?).
I think that developpers still use TFVC because:
The developper don't have the knowledge and the time to train themselves
They are trapped in TFVC without easy tools to migrate (My current customer want
Support in Visual Studio is not satisfying (use instead GitExtensions or SourceTree)
The better idea that Microsoft could have is to add the possibility to TFVC users to do checkin locally to avoid the bad practice that I see every time where developpers has hundreds of modified files before checkin because there is nowhere to put and they don't checkin until they are sure to have found the good solution at their problem (and shelveset accept only one "changeset", so are not used. And branches are really painfull to use in TFVC and each user can't create it's own branch 🙁 )
To finish, I think that to migrate history from TFVC to pure git or TFGit, you'd better try git-tfs ( github.com/…/git-tfs ) which is much more advanced and support:
workitems
labels
But migrate from TFVC is very long because TFVC is quite slow too…
PS: Every help from Microsoft is welcomed to make a good migration tool ( a TFS sandbox repository with all these strange cases, help from a developper, documentation or advices, review of code, even some cash to be able to work on the project,…)
To me Git makes more sense for projects where people contribute to. In a controlled delivery team, TFVC makes more sense
@Charles Ryan you need to do some research into user experience. the "modern-ui" styling in applications is built on some of the most indepth research into optimal user experience. It's fine to debate choices Microsoft made in regards to its OS as a whole but there's no debate that modern-ui applications done well are empirically more accessible and more discoverable to users.
@Chris Marisic
Sorry, theory and practice are 2 different things and my theory is whoever designed the Windows Store App style needs a lot more practice.
@Lambros Vasiliou
For me TFVC has sense where Git reach its technical limits ( You've got a HUGE number of files in your workspace and can't use submodules or manage a lot of binary assets). And there should be a few projects like that. Otherwise, Git is MUCH better that TFVC!
add chunk of files also
Atomic commit is a must
Branch management is MUCH simpler
Viewing branch history permit to better understand the project
Easy checkout of a old revision
Better "blame/annotate" by being able to go deeper in history
bisect
multiple workflow possible
Pull request invert the way someone could contribute to a project
Not being obliged to create a central repository to begin development (very important to do quick proof of concepts)
etc
Lots of small things that makes a BIG difference in the end (and it does not depend of the team but you're right TFVC make very difficult to do a contributive project )
Git is a tool that help the developper to do a better job where TFVC is just a shared backup.
@Brian
I think that people are afraid because they have understood that in the future all VCS should have some features introduced by DVCS and that products that could not evolve will be throw away to be replaced by DVCS.
DVCS introduced features so empowering that you won't be able to stay with not efficient tools.
So the question is more :
Will Microsoft be able to introduce these features and shrink the gap? (Reallly hard thing to do!!)
Or at one time Microdoft will stop development because DVCS has won (I think they already have and each new project MUST be a Git one) and your customer will be trapped in a deprecated tool?
@Philippe Microsoft HAS already stopped all new feature development of TFVC…"token minor features….blah blah blah…"
Anyone who's clued in understands GIT DVCS has ALREADY won.
Apple/Google/Xbox/RedHet/Cisco/HP have ALL embraced GIT as THE STANDARD in their development tooling and engineering processes in the last 5 years.
GIT's DVCS leapfrogs centralized TFVC by orders of magnitude in efficiency and productivity for the engineering team.
TFVC will be around for another 10 years…just like their are developers are still writing VB6webformswinform code.
The TFVC cheerleading crowd will be around too…but they will be completely and utterly irrelevant in a year and COBOL-esqueobsolete in 3 years.
Ride the wave and embrace GIT or enjoy the tsunami into obsolescence.
@Scott – Regarding the git-tf capabilities, as others have noted here, it does not migrate the full history, branches, or labels from TFVC to Git. It was initially built with "bridge" scenarios in mind, though it is capable of migrating history for a single branch.
Taking the conversation up a level, we do not believe that attempting to migrate branches and labels from TFVC to Git is a good practice (even if it is possible to do). TFVC and Git are fundamentally different models when it comes to how branches are persisted and how history is maintained. For this reason, any attempt to migrate from one system to the other will result in a low-fidelity transfer, bloat, and unnecessary friction for developers trying to use the new system.
For teams that are migrating from TFVC to Git, I often recommend to use the transition as an opportunity rather than lament the "loss" of history. Branching best practices in TFVC and Git are so vastly different that it makes sense to construct a new strategy, considering the requirements of your team and the guidance from the experts/community in the process. I like to think about this from the perspective of a city planner: if people in your city will primarily travel via automobiles your city will look different from one designed primarily for pedestrian traffic. If you're a pedestrian without access to a car, you won't be happy living in a city designed for cars. The same is true for your branching strategy – consider your requirements and the capabilities of your VC system and you'll be able to design an optimal strategy (keeping your devs happy and productive).
And for those that don't want to lose your history, that's the greatest part about TFS/VSO – you can keep your history in TFVC while adding new Git repos. Once we finish #9 in Brian's list, moving work items won't even be necessary.
I could accept this idea in some case (even if not being able to do a git blame could be boring). But if you've got some branches living next to your main branch and that you merge sometimes, or other long running branches, I don't know how you could migrate without history without loosing a lot of information 🙁
I really don't know if we could migrate a REAL project just by migrating the last changeset…
PS: Perhaps, I could appear a little harsh in my comments but that's not my intention and I am really waiting for TFS2005 which, with Git and Build.vnext, will perhaps be the first version I will really love to use! You are doing really good work, especially since TFS2012.
TFVC
Labels should show up in the view source code history for file abc.cs and not require a different command to show labels (cvs/subversion got this well over ten years ago)
A check-in policy to prevent check-ins of unmodified files needs to be added (and not require extra scripting/C# code to be added on top of TFS)
Rename / move directory / repository should be supported – Consider moving to a different underlying vc system data store instead of SQL Server. Spend time on migration of changes, commit messages, dates/times, … from SQL Server repository to git or another version control system. Use TFS as the front end to git.
In visual studio, one should be able to edit backlog items without keystroke hijacking done in the notes/comments edit boxes (i.e., use a wpf/xaml control and not a web page for entering backlog items when editing them inside visual studio 2012).
Build definitions should be kept under version control. This is obvious and has been done on the CVS/subversion side for well over 10 years – run external build tool – if build fails rollback commit – if unit tests fail rollback commit.
Compare tools should actually work when comparing large branches (i.e, let it skip DLLs, exe files, and other binaries)
Unmap/remove workspace should not delete your workspace until X days afterwards set by the administrator. This deletes the shelve sets which may need to be accessed for a few days after the workspace is deleted.
TFSVC should store binary files effectively since many projects check them in frequently (e.g., image assets for a web site, dlls built by another project, …
One should be able to build a given project, run unit tests and if the unti test pass, build a second project, then run unit tests for that project…. This should just work without requiring a full build and link of all projects before running any unit tests. This cost us many hundreds of hours over the last 2 years for a large C#, xaml, and back-end services project. Link times were usually over an hour for a 1+ million line project.
User Voice items for TFS should be put into 3 buckets within 3 months of creation 1) in the next version of TFSVC, 2) in a future version, 3) nice to have but we'll never implement it. This will avoid the low fidelity 'we're considering it' answer which is over 2 years old with no follow-ups.
Generally, many products seem to be in zombie / life support state with no real updates or enhancements. Why should a company pay many hundreds of thousands for locally hosted server based software with no updates? Consider the lack of server OS updates in the early 2000s during a time when IT shops licensed it for X years expecting actual support, bug fixes and new features. Combine with Silverlight's 3 years from the first usable version (v2 which added form controls) until v5 was announced to be in the not to be updated category. The bulk of revenue comes from large corporations and should get the bulk of the new features/updates (i.e., the nice/cool javascript scaffolding of the month is good but it it too narrowly targeted for large corporations).
@Brian
FIRST: Please do not remove TFVC
There are much comments about TFVC ist/should be dead.
But there are really some important Features in TFVC you could never get in GIT.
My Wishlist for TFVC and TFS:
1) Purge from VS with Admin-Rights.
2) Purge a file about ALL Branches. (Checkbox in a Purge-Dialog)
3) Purge only old Content of file. Let Content of latest Changeset be the Content for all Changesets before.
And this should work automatically for every Branch including this file!
This would be very practicable for Binaries, that will be checked in automatically from buildserver.
(Checkin Binaries from the Buildserver would not be a recommended way. But in some Scenarios it is VERY useful.)
And of course free this old unused Content in database.
4) "Undo unchanged files…" as an Context-Menu like "Undo…" in PendingChanges-Dialog.
This could not be so hard to implement!!!
This would be very practicable.
Some time you have to checkout a dir with many files, to edit it with an non VS-Editor or Generator.
Of course you could checkin all files and in the changeset there will be only the changed files.
But you will see the changes before checkin. So "Undo unchanged files…" on the dir and …
5) ALL PowerTools-Extensions for TFVC please in the VS-Release.
Find by Status, ….
This very useful extensions are in PowerTools since VS2010. Shame about (whoever), that this was not integrated to VS. I can understand that you have PowerTools for NEW extensions. And not to give Support for this.
But very useful Features that are included in the last PowerTools SHOULD be fix integrated to the next VS.
6) Please integrate the Features of the TFS-Sidekicks also to VS.
TFS-Sidekicks are very useful and every TFS-Admin should use it. TFS-Sidekicks are not from MS.
But it is a free tool. So nobody can blame you, if you integrate the same admin-functions in VS.
7) Moving a ticket from one Teamproject to an other Teamproject. (Of course the Definition of the Ticket-Types must be exactlly equal. (Imported from the same XML).
8) All WebAccess-Only-Features ALSO in VS-TeamExplorer!
9) Whats about something like an Merge-Server???
10) A own Property that you could be set on paths to hide this path (eg a whole (old) branch) ONLY in Source-Code-Explorer AND a Switch-Button (like Show deleted). If you have Long-Long-running Teamprojects and you have a lot of a lot of branches then this would be very useful. You could use also the read-Rights, of course. But then you will also see no Changesets if you make a anotate, track changeset, …. And this will be very silly if you only will hide old branches in Source-Control-Explorer. Now we use a Workaround. On old branches we make DEL on the branch and then we remove all rights – except read. So without show-deleted this branch is hidden, but you can see all changes in this branch if you track a changeset. And in a Feature-branch the initial changes would be there. But with this Workaround you lost this Feature-branch. You can not reopen it. Of course you can. Set the rights back and revert the DEL. But if you checkin new changesets you can not reverse-integrate them, because of the DEL/Revert on the Branch. Maybe it will work. But the risk is to high to have multiple DELs with reverts for nearly all files on the trunk.
11) In the view of the Pending-Changes: Date of Check-Out!
12) Something like a Report for an user OR all users to Show all: Workspaces, Shelvesets, PendingChanges, …
Or only a summary with Counts.
So you can easily control if a developer is gone. Now you can make this with TFS-Sidekicks.
Also nice for TFS-Upgrades. Then you can easily check if there any PendingChanges or mapped workspaces before upgrade. In the most times an upgrade will work also with PCs an WS mapped. But I will prefer to make Upgrades (for TFS-Major-Upgrades on new Hardware) without open PCs and WSs. A list wist all users and Counts would be fine.
@Ted @Holan
Thanks for the detailed feedback/wishlists. Ted mentioned the visualstudio.uservoice.com site, which is a great place for entering feature requests like this. It is a bit more visible than blog comments, and enables voting, so we can gauge overall community interest.
Also, regarding the staleness of some uservoice items – our team is in the midst of a triage of open suggestions, and we have a new process that will allow us to periodically revisit popular suggestions to update them with the latest status.
@Holan Microsoft won't remove TFVC, no worries there….but your list of improvements is a pipe dream. Microsoft is not interested in delivering new features on TFVC…see the comments above and lack of delivered features since 2013. TFVC is mature and…well its "done".
Move to GitGithub and start using atlassian SourceTree. Source Tree is a great tool and has several features you are looking for.
@DaveA, Dude, that's enough. That's not what I said. You've twisted my word "mature". I mean very capable. I have a long list of features there which are significant and involve active development in TFVC. We'll continue to invest in TFVC and make the experience better. You have your own opinion and that's cool but please stop stating it like it's fact.
Brian
@DaveA
Sorry to say that. I did not know you or Brian personally.
But I see this Forum from Brian and it is one of the best and openminded and know-how-sharing Forum I ever seen.
So, if you ask me: Whom I will trust more, Brian or an user, who recommend a third-party-tool (not open source).
I Think you know, what my answer will be. 😉
Best regards
blogs.msdn.com/…/the-future-of-codeplex-is-bright.aspx
Is Codeplex dead?
Hi Brian. I love the transparency and would like encourage to continue sharing. This type of sharing, regardless of how others might feel, is a valuable tool for us on the frontline to plan and made decisions. Your transparency have been valuable and we are looking forward to the upcoming improvements to the product. And yes we are using TFS GIT and TFSVC and the many valuable capabilitiesfeatures the TFSVSO gives us as an integrated solution.
Norm
hi Brian, I just translated this post into Chinese and posted on my blog. Hope this will help the Chinese developers to know more about the latest news from TFS team.
anb.io/…/the-future-of-team-foundation-version-control
Lei
Brian with the open sourcing of MSBuild what are the plans to open source TFS and TFVC? blogs.msdn.com/…/msbuild-engine-is-now-open-source-on-github.aspx
You mention there are a bunch of people at MS using TFVC for version control, which teams are staying on TFVC and why have they chosen to stay with TFVC over GIT?
@yaosio, There are so many teams using TFS and/or VS Online that it's impossible to list them or articulate their reasons. But, as an example, the SQL Server team has been a long term user of TFS. They use TFVC and on prem TFS and they are happy with it and last I checked had no plans to change anything soon. Will they change something someday? Probably. I don't know what and I don't know when. Teams periodically evaluate their options but changes in source control systems are not changes you make lightly or often. The Azure team is a good example of a team that went with Git (and I don't think even that is uniformly true across all of Azure but is true for a large part). They were previously not using TFVC, they were using an older internal version control system. They've moved to TFS and Git and plan to eventually move to VSO.
Brian
Brian, when is TFSVSO going to have version control support for Mercurial? Codeplex had support for Mercurial in 2012 and TFSVSO really needs to have it. Take a look at this great talk from Facebook about how they've moved from GIT to Mercurial monorepo and why Mercurial works so well at scale.
gregoryszorc.com/…/notes-from-facebook%27s-developer-infrastructure-at-scale-f8-talk
Facebook employees run >1M source control commands per day. >100k commits per week. VCS tool needs to be fast to prevent distractions and context switching, which slow people down. Mecurial does slow people down like GIT or subversion or TFVC.
@JKabbes, We don't have any near term plans to add Mercurial. I'm familiar with what Facebook has done, though I haven't yet read their most recent descriptions. We are looking at making some changes that will make VSO/TFS integrate better with other version control systems. Stay tuned for more on that.
Brian
+1 on better integrating with other source control systems from TFS–>REMOTE and REMOTE –> TFS. We have partner teams on SVN and CVS and we are having to do manual latest copies daily/weekly of the HEAD of their REMOTE into branches in TFS. It's a heavy tax to our dev team productivity, but merging code changes requires human interaction.
Facebook's engineering efforts on Travis CI and mercurial are representative of truly impressive engineering.
Facebook has a 54 GB repo (as of almost a year ago, April 2014). And now they are mentioning 50x and 2000 improvements to mercurial. These are aren't trivial numbers when you consider Facebook open sources their work. And not in the "throw it over the wall" sense. Facebook's open source projects tend to gain traction and get a significant amount of community contributors.
I haven't dug into Travis CI very much and compared it against the new build system that's coming in VSO…but now I'm keen to want to understand Facebook's tooling and development strategies as they really have successfully embraced mobile and agile development. We need best of breed tooling and using code coverage to determine what tests to run is a great approach I haven't seen natively offered in TFS/VSO.
"Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project."
"We made mercurial up to 50x faster than git, more than 2000 improvements" on big repos with lot of history.
Blog post about this: code.facebook.com/…/scaling-mercurial-at-facebook and the code at selenic.com/…/shortlog
How does Microsoft scale GIT with TFS/VSO? How does TFVC compare with mercurial?
Coexistence (#8) would be really good. I imagine it's a very hard job though. Git has branching in the time dimension while TFVC has it in the namespace. Making it work at all seems doable but are you going to actually reconcile that? Just thinking about it makes my brain hurt.
Hey Brian,
Can you publish a table comparing TFS support of git and TFVC features? Similar to http://www.visualstudio.com/…/compare-visual-studio-products-vs.aspx.
This would make it easier for people like me who are trying to decide which to go with for their next project. And reinforce to people that work is still being performed on TFVC.
Make the functionality names links to blog entries describing them.
In cases where TFVC does something GIT does not or visa-versa, indicate when they are expected to be added if at all.
Add more items as people inevitably bring them up.
Ex:
Functionality | GIT | TFVC
New Code Search | Yes | Coming before VS 2015 is released.
Thanks for the all the updates on git and TFVC!
Awesome, I'm really looking forward to the iterative code reviews
@Steven For a new project, there's no question at all… Choose Git !
The only problem is with big binary files and a lot of projects could live with that and I am pretty sure that Microsoft will soon implement git-lfs (like github) to handle them easily. Things that should not be too difficult to handle for the TFS server…
@Steve, Here's my attempt to answer your question: blogs.msdn.com/…/tfvc-amp-git-support.aspx
Brian
Thanks for posting on the future of version control! I'm a little confused by the term. Is TFVC the same as server source control? And is it used mainly by developers?
@Eliza, TFVC is short for Team Foundation Version Control and is a centralized version control system in the same genre as Subversion – but dramatically more scalable than most centralized version control systems and with mature "enterprise" features – like high availability, online backup and restore, etc.
Brian
I remember the same discussion (at Microsoft) around Silverlight where I was promised that Silverlight was Microsoft's big thing and Microsoft wasn't going to drop it in favour of HTML5 yadda yadda. Two years later Silverlight just dies, silently. Reading the above almost feels like I'm reading the Silverlight blogs.
I especially love point 5… building something into Git before TFVC and then actually use that same item as a talking point for TFVC's proof of life.
We've just moved all our source control to VSTS, let's see if someone from MS suddenly pulls the plug on it in 2 years and we have to begin the entire migration to Git.
I’ll add to Fran’s comment:
In Brian’s list of examples about all the work being done “around the core”, NOT ONE of them is related to “core” tasks of version control (branching, merging, tagging, history, check-out, commit, etc.). It’s like the TFVC paradigm of “version control” is centered on tools AROUND version control, and is more or less dumb to what good source control practices actually are. From what I’ve observed, this view carries into the TFS community as well. Those who understand good practices stick with something like GIT or SVN, and those who don’t jump onto TFS because of all the fancy tools.
Seriously, what kind of version control system does not support a concept of externals aka sub-modules? Or does not make core source-control issues (like proper merging) a priority over TOOLING?
Amen to the “mature” paradigm as well. Seriously, a “mature” version-control system is not even focused on what makes a good version-control system??
(..I realize I may be talking more about TFS than TFVS, but the thinking is the same: if you are using TFVS with GIT, then GIT *is* your version-control system, and everything else around it is just a TOOL to access it).
So what about support for Access? Yes, I agree, we shouldn’t be developing large complex UI’s based on Access, but I can’t sell the year+ of time it would take to port my Access app to something else. So for the short time, I’m stuck using Access…but as of Access 2013…MS has pulled Access support to TFVC…kind of leaves a lot of us in the lurch.
What is the new option?
Thanks,
CJ
A lot of time has passed, and more and more integration between TFS and Git have been done since you posted this blog. I am interested and wondering what your thoughts were now (two years later) with respect to TFVC “going away” or being abandoned by Microsoft.
I am currently exploring moving my company’s product code to Git/GitHubEnterprise, which has been in TFS for at least ten years with great success and a ton of releases later, because some of the management sees the trend of Microsoft putting their own code in Git and perceives that as a “business risk” of TFS being shuttered. I personally believe that TFS isn’t going anywhere for a long time as you stated two years ago. But trying to convince management of that is difficult when they see what MS is doing. In just my short time using Git, I can see no other real tangible benefits over what TFS already provides with the way that we do development. So moving to Git won’t really increase our productivity which is what they also think will happen with a DVCS.
What would be your approach, and message to dispel the perceived “risk” of not having TFS supported anymore in a some number of years, and also how staying with TFS will not be minus in the productivity category vs. Git? Thanks.
@JPRSAArcher, Some thoughts… I think my message today would be mostly the same. We have both, we support both. I’d be cautious about trying to read tea leaves. Here’s an answer I gave to a comment on the post that I suspect someone is thinking of:
Sure, in terms of active users on Team Services, TFVC is about twice as large at Git but Git is growing a little faster. I haven’t tried to plot the theoretical cross over point (where Git passes TFVC) but the grow rates are both good enough that it’s reasonably far out in the future – beyond any time horizon I would try to predict.
TFVC is still very popular. It’s good at what it does and we’ll continue to support it.
One question I have is why move off TFS? If you want to try Git, try it. TFS has it – one of he best Git implementations around, as a matter of fact. You can create Git repos in the same projects as your TFVC repositories. Pick projects to experiment with, etc. If you decide moving to Git is what makes sense for you, you can do so at a comfortable pace. If you decide it’s good for some projects and not others, that’s good too.
Brian