Немного об SCM в Microsoft

Добрейшего.

На RSDN в ходе дискуссии кинули ссылкой на заметку, датированную 2006 годом, написанную бывшим сотрудником Microsoft.
Мойша (автор) писал, в основном, касательно бюрократии, царившей в конторе, на примере работы над своей фичей. В довесок было также упомянуто вскользь о политиках контроля версий и о том, как они добавляли неповоротливости в и без того неповоротливый механизм. Ниже - оригинальный текст и некоторые выводы из прочитанного.

In Windows, this model [централизованного репозитория - прим. ред.] breaks down simply because there are far too many developers to access one central repository. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.

Итак, у них иерархия репозиториев.

• В корневом лежит наиболее стабильная рабочая версия системы, которая имеет определенные версии входящих в неё подсистем (hardware, core, UI и т.п.). Это 1 уровень.
• Каждая подсистема разрабатывается в своём репозитории. Из корня берется послденяя доступная версия системы и от неё идет разработка. В "корень" отправляются лишь стабильные версии подсистемы путем репликации (или же хитрой миграции). Это уровень 2.
• Подсистемы состоят из компонент - и для каждой тоже есть свой репозиторий, с копией последней стабильной подсистемы (и какой-то версией всей операционки). Это уровень 3. В нём компонент созревает и периодически отдается в подсистему уровнем выше.
• Последний, 4-й уровень, содержит наименьшие атомарные модули (с разной свежести версиями подсистем, компонент и т.п.) и отдает результаты работы на 3-й уровень.

Вот и получается, что для того, чтобы код конечного разработчика попал от него в корень (т.е. в код операционной системы) - он интегрируется сначала в компонент, проверяется, потом в подсистему, снова проверяется, а затем уже в код системы. И чтобы разработчику получить для работы последнюю стабильную версию системы, ему надо дождаться, пока пройдет обратная миграция кода (propagate, "пропагейт") - от корня к конечному репозиторию. Что ж, есть в этом своя логика. Жаль, что переходы между уровнями шли так долго.

Кстати, немедленно вспомнилась моя же заметка про основы СМ и базовые конфигурации. А именно - фрагменты с картинками о компонентах, суперкомпонентах и продуктах. Только у МС всё значительно сложнее.

Есть ещё сложности при таком сценарии, про них писали в комментах - с циклическими зависимостями. Если модуль А зависит от модуля Б, и Б зависит от А, и кроме того, они находятся в разных репозиториях это значит, что:

1. для разработки, отладки и предварительного тестирования надо иметь в одном из репозиториев результаты обеих модулей, т.е. сделть модуль А, дождаться реплики на ноду выше, дождаться пропагейта из ноды - "вниз" к модулю.
2. в продукт или подсистемы выше уровнем надо подавать на интеграцию изменения параллельно.

Вообще, управление зависимостями - задача очень нетривиальная. И будь это всё в одном центральном репозитории - проблем бы вообще не стояло. Но тут - иерархия, приходится как-то крутиться.

Итог такой организации работы: изменения проходили снизу вверх и обратно очень долго, месяцами - и это очень плохо.


Комменты
Само собой, комментов - раскинулось море широко. Большая часть - высказывания про саму фичу, но мне же показалась интересной следующая инфа:

The current source code management setup in Windows was introduced by Mark Lucovsky (him who Ballmer threw a chair at when he announced he was joining the big G). The VCS is called SourceDepot and it's a modified version of Perforce.

В общем, при работе над Вистой (как, наверное, и при работе над более ранними версиями) использовали систему контроля версий, именуемую СорсДипо. Она является разновидностью Perforce (P4, Перфорс), проприетарной системы контроля версий. Мне довелось работать с ним немного плюс слышал от коллег разное. В общем, да, выбор неплохой. Надо полагать, Перфорс доработали для Майкрософт именно в сторону распределения репозиториев. Не путать с распределением всей системы контроля версий - всё-таки Перфорс является централизованной системой контроля и репликация репозиториев ещё не делает её "гитом". Кстати, некоторые возможности, вроде аналога конфигспеков, делают её приближенной по возможностям к ClearCase.

Так-то так.
Интересно было бы узнать, используют ли в МС по-прежнему СорсДипо (заметка Мойши ведь от 2006 года) или уже полностью перешли на TFS даже для создания Windows? По крайней мере, руководства по TFS-ному СМ они пишут во всю.

P.S. На отдельной странице собраны ссылки на статьи по основам контроля версий и вообще управлению конфигурациями.