Main Content

Windows switch to Git almost complete: 8,500 commits and 1,760 builds each day

Back in February, Microsoft made the surprising announcement that the Windows development team was going to move to using the open source Git version control system for Windows development. A little over three months after that first revelation, and about 90 percent of the Windows engineering team has made the switch. The switch to Git has been driven by a couple of things. In 2013, the company embarked on its OneCore project, unifying its different strands of Windows development and making the operating system a more cleanly modularized, layered platform. At the time, Microsoft was using SourceDepot, a customized version of the commercial Perforce version control system, for all its major projects. SourceDepot couldn’t handle a project the size of Windows, so rather than having the whole operating system in a single repository, the Windows code was actually divided among 65 different repositories, with a kind of virtualization layer on top to produce a unified view of all the code. Some of these 65 repos contained nicely isolated, standalone components; others took vertical or horizontal slices through the operating system; others were just grab bags of different code. As such, the repo structure didn’t correspond with OneCore’s module boundaries. Microsoft wanted a structure that better fit OneCore. It also wanted a system that better fit the development of “Windows as a Service” and the move from making one major release every three years to making a smaller release every six months. Windows development has been substantially opened up compared to the Windows 7 and Windows 8 days, with much more customer feedback through the Insider Program. The development team is trying to be much more responsive to bug reports and suggestions coming from Windows users, and this changed the demands placed on the version control system. Even with its customization and multiple repositories, the scale of the Windows codebase, some 3.5 million files in total, pushed SourceDepot to the limit. Creating a branch took the better part of a day, with a performance-imposed limit of about 500 branches total. Groups had to think long and hard about whether they would actually create a branch—they certainly weren’t going to create one on a whim—and would then have to scavenge someone else’s branch if they decided that they really needed one; they would have to find an old, unused branch and ask the team that created it to kill it off so that the system would have capacity for the new branch. Addressing these performance concerns was the second big driver for the switch away from SourceDepot to something new.”

Link to article