Автор: Брайан де Алвис, Джонатан Силлито
Источник: 2009 ICSE Workshop on Cooperative and Human Aspects on Software Engineering
Брайан де Алвис, Джонатан Силлито. Почему программные проекты переходят из централизованного в Децентрализованные системы контроля версий? Системы контроля версий необходимы для координацииработа над программным проектом. Ряд открытых и закрытыхисходные проекты предлагают перенести, или ужеперемещены, их хранилища исходного кода из централизованногосистема контроля версий ( CVCS ) для децентрализованной версиисистема управления ( DVCS ). В этой статье мы суммируемразличия между CVCS и DVCS и описатьнекоторые из обоснований и предполагаемых выгод, предлагаемыхпроекты, чтобы оправдать переход.
Для многих проектов, их системы контроля версий ( VCS ),наряду с другими инструментами, такими как система отслеживания проблем,имеет решающее значение для организации работы по разработке.Главная проблема в управлении разработкой программного обеспечениямасштабирование процесса изменения до большого числа возможногеографически распределенные разработчики программного обеспечения безжертвуя качеством или вводя неоправданные накладные расходы. КВ значительной степени эти инструменты определяют, насколько легко люди могутвнести свой вклад в проект, как разработка новых функцийсогласовано, как часто отдельные линии развитияобъединены, как код проверяется и как поддержкаготовый выпущенный код организован. Несмотря на их важность,влияние, которое эти инструменты могут оказать на разработкуи соответствующие компромиссы еще недостаточно изучены.
Новое поколение VCS , называется децентрализованной VCS с( DVCS ), которые касаются некоторых ограниченийтекущих централизованных VCS ( CVCS ), таких как CVS [1, 3] и Subversion [2] , чтобы лучше поддерживать децентрализованные рабочие процессы.Некоторые из этих новых DVCS, такие как GIT, МERCURIAL, BZR, и BITKEEPER, стали достаточно зрелымичто многие проекты с открытым и закрытым исходным кодомпереместить или уже переместил свой исходный кодхранилища для DVCS .
В рамках более крупного исследовательского проекта по изучению практикии инструментальная поддержка вокруг управления версиями, у нас естьначал качественное исследование, чтобы ответить на два вопроса исследования.Во-первых, что эти проекты видят в DVCS ? Переход хранилища исходного кода на новыйVCS требует значительных усилий, и поэтому мы предполагаем, чтодолжны быть веские причины для переключения. Во-вторых,Какие изменения эти проекты внесли в их развитие?Процессы при переключении? Чтобы ответить на этивопросы, мы изучили общедоступные документы иобсуждение списка рассылки для четырех проектов с открытым исходным кодом (Perl,OpenOffice, NetBSD, Python), которые были перемещены илирассматривает возможность перехода к DVCS для определения обоснования ипредполагаемые выгоды, предлагаемые проектами для оправдания такогоsition. В этой статье мы представляем некоторые начальные наблюденияиз нашего текущего анализа.
В этом разделе мы даем краткое описание обоихцентрализованные и децентрализованные VCS , и выделитьпроекты с открытым исходным кодом. Обратите внимание, что в качестве различных реализаций DVCS все еще находится в стадии быстрой эволюции,подробное пошаговое сравнение текущегоинструменты быстро устаревают. Скорее мы сравниваемконцептуальные различия между CVCS и DVCS , ивместо этого направьте заинтересованных читателей к черновому опросу Раймондаиз VCS с для сравнения подробно [5] .
Наиболее часто используемая система контроля версий ( VCS )сегодня используются централизованные VCS , как это указано в CVS [1, 3]и Subversion [2] . Эти VCS централизованы, поскольку они имеютединый канонический исходный репозиторий. Все разработчики работаютпротив этого хранилища через проверку, взятую изхранилище, по сути снимок в какой-то момент времени.
Доступ на запись в репозиторий группы обычноограниченный набор известных разработчиков или коммиттеров. Вс открытым исходным кодом, коммиттеры обычно зарабатывают иподдерживать доступ на запись посредством представлениякачественные патчи, чтобы продемонстрировать мастерство программирования ипонимание конвенций развития проекта.Команды обычно устанавливают правила и практику кодированияконтролировать, как вносятся изменения в хранилищесохранить качество исходного кода.
Современные VCS поддерживают параллельную эволюцию хранилищасодержание за счет использования веток. Один широко распространенныйпрактика состоит в том, чтобы поддерживать основную ветвь для представлениятекущие усилия по развитию, и создание новых отраслейосновная линия для представления выпущенных версий продуктаи отслеживать исправления ошибок в выпущенном продукте [4]. ветвитакже часто используются для проведения существенных измененийкакой-то большой продолжительности, с целью объединенияв основную линию.
Чтобы обеспечить первоклассный доступ для всех разработчиков: ключпричина, по которой многие проекты перешли на DVCS, заключалась вулучшить поддержку не-коммиттеров. Авторы безфиксация доступа не может получить выгоду от CVCS для ихработать, и часто прибегают к созданию параллельных хранилищ дляуправлять большими изменениями. В обсуждении Python этот вопросБыло подчеркнуто, что наиболее важным ограничением ВАХ скак любой, кто пишет патч для Python или создает кастомверсия, не имеет прямой инструментальной поддержки ревизий
. Фонд Perl уделял особое внимание использованиюDVCS с открытым исходным кодом, чтобы гарантировать, что инструменты были доступнывсем членам сообщества. Разработка OpenOfficeПроцесс опциона, основанный на использовании веток CVS , требует разработчика иметь доступ для записи в хранилище.
DVCS захватили большой кругозор, и многиепроекты, по крайней мере, обсуждают достоинства перехода иххранилища кода для DVCS . Наше исследование предоставило некоторыепонимание ограничений CVCS и последствийэти ограничения имеют для команд разработчиков. ХотяDVCS решают некоторые проблемы CVCS , в частности трудность повторного слияния ветвей, наши выводыпредположить, что DVCS может также представить новые проблемы.
До сих пор мы только исследовали, какие члены командыполагаю, что последствия перехода на DVCS будут.Эти убеждения привели нас к формированию нескольких гипотез (например,не-коммиттеры сделают более значительный вкладв проекте с DVCS ), который мы хотели бы изучитьв дальнейшем. Нашим следующим шагом в этом исследовании будет проведениеопрос разработчиков , которые имеют опыт работы с обоими DVCS sи CVCS s. Мы заинтересованы в том, чтобы задавать такие вопросы, как:Переход на DVCS действительно уменьшил барьеры дляipation? Как изменились их процессы разработкив результате DVCS ? Какие новые осложнениябыл введен с помощью DVCS ? Какие рекомендациибудут ли они сделать для других проектов, рассматривающих переключениев DVCS ? При каких обстоятельствах они посоветуютпротив внесения таких изменений? Есть ли различия в DVCS использовать между разработкой с открытым и закрытым исходным кодом?