Использование Subversion для командной разработки

Большинство современных проектов не пишутся в одиночку, и перед разработчиками встает проблема совместного владения кодом и другими артефактами проекта.

Если над проектом работает всего лишь несколько человек, объединение внесенных изменений в общую версию может занимать много времени. Для решения данной задачи используют системы управления версиями (от англ. Version Control System (VCS) или Revision Control System), которые позволяют хранить в централизованном репозитории множество версий артефактов проекта (документов, файлов и т.д.).

Репозиторий — хранилище каких-либо данных. Данные в репозитории обычно хранятся в виде файлов или с использованием систем управления данными (СУБД), которые обеспечивают надежные механизмы для манипулирования данными.

Даже если над проектом работает один человек, то использование систем управления версиями оправдывает затраченное на их изучение и конфигурирование время.

VCS являются удобным репозиторием для исходного кода проектов, позволяют хранить всю историю изменений, что в свою очередь позволяет восстановить и пересобрать любую версию проекта (например, для воспроизведения разработчиком найденных тестировщиками ошибок в программе), восстановить удаленный блок кода и т.д.

В мире свободного программного обеспечения (ПО) наибольшую популярность приобрели VCS системы такие как Concurrent Versions System (CVS) и Subversion (SVN).

Многие компании по разработке программного обеспечения выбирают именно Subversion, так как данная система была разработана специально для решения ряда проблем устаревшей системы контроля версий CVS и позволяет обойти некоторые ограничения присущие CVS. Subversion распространяется по свободной Apache/BSD-style (http://subversion.tigris.org/project_license.html) лицензии и доступна по адресу http://subversion.tigris.org. На сайте проекта доступны бинарные версии сборок для различных операционных систем, так же доступен исходный код, который может быть использован для самостоятельной компиляции. По адресу http://svnbook.red-bean.com доступна электронная книга “Управление версиями в Subversion” переведенная на многие языки включая, русский, с детальным описанием архитектуры и принципов работы с SVN.

Разработано несколько клиентских графических интерфейсов для упрощения работы с данной системой управления версиями. Для операционной системы Windows разработан удобный, встраиваемый в оболочку Windows клиент TortoiseSVN (http://tortoisesvn.tigris.org). К сожалению, при работе с большими проектами, которые содержат несколько тысяч файлов, возможны неконтролируемые “замораживания” системы на некоторое время. Это вероятно связано с рекурсивными операциями TortoiseSVN по кэшированию файлов проектов при попытке войти проводником Windows в каталоги, которые содержат SVN проекты. Тем не менее, данной программой довольно удобно пользоваться, несмотря на данную проблему.

Обычный цикл работы над программными модулями заключается в следующих этапах:

Обновление локальной (рабочей) копии проекта и содержимого репозитория;
Правка ресурсов проекта;
Фиксация изменений.

Связанные с Subversion команды доступны из контекстного меню “ Team ” любого ресурса проекта. Статус ресурсов проекта помечается оверлейными иконками. Например, вопросительный знак показывает, что ресурс не добавлен в репозиторий, черная звездочка отмечает ресурсы, в которых сделаны локальные изменения, а плюс указывает, что ресурс помечен на добавление в репозиторий. Обновление рабочей копии и содержимого репозитория осуществляется вызовом команды “ Update ”. При этом, часть ресурсов, измененная другими разработчиками сливается с текущими изменениями локальной копии проекта. Иногда возможны ситуации, когда система не может автоматически решить конфликты слияния и данную операцию приходится делать вручную. Мастер разрешения конфликтов вызывается командой “ Edit conflicts ”. Практика показывает, что при периодическом обновлении локальной версии количество конфликтов сводится к минимуму (обычная практикой является обновление проекта перед началом работы). Если локальная версия не зафиксирована в репозитории, то перед обновлением локальной копии проекта полезно делать архив текущей версии. Это позволит снизить потери времени, если вдруг окажется, что версия в репозитории находится в нерабочем состоянии. После добавления новых локальных ресурсов в проект их надо пометить для добавления в репозиторий командой “ Add to version control ”. Часть локальных ресурсов создается автоматически при компиляции проекта. Обычно такие ресурсы помечаются системой контроля версий как игнорируемые. Для этого служит команда “ Add to svn:ignore ”. Это позволяет снизить сетевой трафик на бесполезную передачу данных.

Существуют различные стратегии фиксации изменений. Особенностью свободных проектов является возможность привлечения сторонних разработчиков. Обычно выделяют некоторую группу ведущих разработчиков, которые вносят изменения непосредственно в рабочий репозиторий, и часть разработчиков с ограниченными правами доступа. Для фиксации изменений такими разработчиками подготавливаются “патчи” изменений, которые проверяются ведущими разработчиками и вносятся в репозиторий. Для работы с “патчами” служат команды “ Create patch ” и “ Apply Patch ”. Патчи могут создаваться как обычные текстовые файлы и пересылаться по почте или прикрепляться как вложения к задачам в системе управления проектами.

Удаление ресурсов проекта выполняется командой “ Delete ” с последующей фиксацией сделанных изменений в родительском каталоге. Для отмены изменений служит команда “ Revert ”.

Фиксация сделанных изменений непосредственно в репозиторий производится командой “ Commit ”.

Если при выполнении какой либо операции работы с SVN нормальное выполнение операции было прервано (например, из-за обрыва соединения с сервером), то для восстановления корректного состояния локальной копии нужно вызвать команду “ Cleanup ”.

Хочется отметить понятие ответственности за сделанные изменения при командной работе. Бывают случаи, когда сделанные вами изменения приводят проекты в репозитории в нерабочее состояние, что может привести к проблемам для остальных участников проекта. На выяснение сути ошибки требуется некоторое время, которое при умножении на количество участников проекта может быть просто катастрофическим. Поэтому, непосредственно перед фиксацией изменений в репозиторий, следует произвести обновление локальной копии командой ” Update ”. После чего произвести перекомпиляцию проекта и прогон тестов. И только удостоверившись, что все работает корректно, фиксировать изменения в репозиторий.

В разных компаниях проблемма ответственности за сломаный билд на сервере решается по разному. Если команда разработчиков сосредоточена локально, то практикуют например маску с ушами осла, которую должен носить провинившийся в течении всего дня. Или картонную фигурку туповатого Симсона, которая торжественно устанавливается менеджером на стол провинившегося вплоть до перехода с следующему несчастному. Это реально действенный метод, так как никто не хочет созерцать это чудо у себя на столе.