Ведение дополнительных веток проекта отнюдь не бесплатно.
Структура репозитория исходников типичного проекта обычно представляет собой дерево:
Основная ветка, от которой отходят ветки подразделений, команд и отдельных подпроектов. Новый код или исправления старого производятся в самых нижних ветках. Затем накопленные изменения перебрасываются в ветку, находящуюся выше по иерархии. При этом код проходит различные проверки, начиная от банальной «проверки временем», до прогона через формальный набор тестов различной сложности. Сложность и скрупулёзность проверок, как правило, растет при приближении к основной ветке. По мере надобности, от основной ветки отпочковываются ветки выпускаемых версий. Именно в них вносятся последние исправления и собирается финальная сборка продукта.
Такая схема имеет много преимуществ. Она позволяет эффективно изолировать разные команды друг от друга: изменения, сделанные одной командой, не мешают работе других. Легко контролировать перемещение кода из ветки в ветку. Код, по мере приближения к корню, проверяется всё тщательнее. Упрощается выпуск очередной версии и заплаток к уже выпущенным версиям.
Как обычно в любой бочке мёда есть своя ложка (а то и несколько) дёгтя. Одна из ложек данном случае, – чрезмерное увлечение созданием отдельных веток даже для самых маленьких фрагментов кода. Это мотивируется двумя аргументами: во-первых, создание все новых веток практически бесплатно с точки зрения необходимых ресурсов (процессорного времени и места на дисках), а во-вторых, инкапсуляция изменений в отдельной ветке повышает общую стабильность кода. Оба утверждения можно во многих случаях считать чистой воды заблуждениями.
Возьмем первое утверждение. С ним, в общем-то, все в порядке, до тех пор, пока размер проекта не вырастает в объеме во много раз. Для больших проектов становится важным и общий объем исходный файлов и время сборки продукта. В случае Windows, например, переключение между разными ветками может занимать больше часа, полная сборка системы и прогон базовых тестов - больше десятка часов даже на очень мощной машине. Кроме того, нужно собирать не одну версию системы, а шесть: отладочную и оптимизированную сборку для x86, amd64 и ia64. Учитывая, что в рабочем дне есть только 8 часов, то приходится либо ждать, либо планировать свои действия заранее. В принципе, это справедливо и не для таких монстров, как Windows. Можно сказать, что это применимо ко всем проектам, время сборки которых превышает полчаса-час.
Второе утверждение еще более спорно, чем первое. Дело в том, что создание отдельной ветки ничего не даёт само по себе. Стабильность кода обеспечивается качеством тестирования, через которое проходит код, перед своей интеграцией в родительскую ветку. В случае веток, расположенных ближе к основной ветке это и автоматическая ежедневная сборка, и автоматические тесты, плюс возможное ручное тестирование и т.д. В случае ветки, которой пользуется отдельный разработчик, ничего этого, как правило, нет. Вернее все должно делаться вручную. Опять же, если мы говорим о большом проекте, то у отдельного разработчика может просто не быть ресурсов для полноценного тестирования. В особо запущенных случаях и с ежедневной сборкой возникают проблемы.
Собственно вывод отсюда такой. Создание ветки в проекте автоматически подразумевает траты из бюджета на сервера (или процессорное время) для сборки и тестирования еще одного или нескольких версий продукта. Иначе ветка становится просто местом, где временно складываются непроверенные изменения.
[...] from blog.not-a-kernel-guy.com. Filed under: [...]
Надо ж, есть люди которые на ia64 запускают Windows
Некоторые, не побоюсь этого слова, извращенцы запускают x86 код на ia64 в режиме эмуляции.
В Sun у нас была только разбивка по тимам. Ветки под фичи не делали, так как обычно все умещается в working copy девелопера, который эту фичу делает. Бывали конечно особые случаи когда товарищ делал один commit из 10 тыс. строчек в тимовую ветку за полгода работу…
Как ты правильно заметил автоматизированное тестирование доступно только большим веткам типа самого транка и крупных групп. Иначе обеспечить запуск десятков тысяч тестов но паре десятков различных платформ практически нереально.
That sounds like a piece of general wisdom - adding code raises the maintenance effort. Actually, I think more interesting aspect of the problem what would be additional maintenance dependent on configuration management strategy and source code control tool.
Well, it is a piece of general wisdom that people keep forgetting about.
It would be interesting. No doubts about that. If only someone would write such an article.
Is that a challenge or what?
If it is going to result in a good article - yes!
Давно ищу хоть какую-нибудь статистику по сборкам проектов, да и по тестированию тоже, чтобы решить, к чему равняться. Может у тебя есть какие-то конкретные цифры чтобы поделиться?
Сомневаюсь, что такая статистика есть. Скажем по ссылке указывается время сборки Windows Vista и Windows Server 2003. Даже если время было точно измерено в секундомером в руке, то все равно эти цифры, по большему счету, бесполезны. Проблема в том, что:
1. Не указано, на какой машине производилась сборка;
2. Не учтено, что сборка это не только непосредственно компиляция кода. Там еще много чего делается в процессе;
3. Не указано что именно собиралось и соответственно не понятно как оценить скорость;
4. Не учтено, что во время сборки дергаются различные сервисы в сети, время отклика которых существенно влияет на общее время сборки.
И так далее. Там ещё много пунктов.
Но самое главное, заключается в том, что даже если всё это учесть, то цифра будет показывать скороть сборки Windows, а нечего либо другого. Другой проект будет собираться с другой скоростью. Причем разница может быть очень существенна. Классический пример - шаблонизированные, boost-оподобные проекты собираются значительно дольше, чем их C-подобные браться аналогичного размера.