Контроль сторонних библиотек с помощью Subversion

Я потратил пол часа, чтобы перевести фразу “managing project dependencies” на русский и всё равно вышло коряво…

Когда я начинал пользоваться Subversion, по старой CVS-ой привычке не мог привыкнуть к тому, что в Subversion “всё, буквально всё,” делается копированием. “Всё” – это и копирование само по себе и создание веток (branches) и меток (tags). Кстати, отсутствие меток в чистом виде я не понимаю до сих пор. Возможно с архитектурной точки зрения это правильно, но с точки зрения пользователя это не удобно – поставив метку пользователь должен озаботится защитой вновь созданной ветки от изменений. Это можно сделать на уровне контроля доступа к репозиторию, но всё равно неудобно.

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

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

/
    external
        library-1
            trunk
            version-1
            version-2
        library-2
            trunk
            version-1
            version-2
    project-1
        trunk
            library-1
            library-2
        version-1
        version-2
    project-2

Все стороние библиотеки помещаются в “/external”. Для каждой создается отдельный каталог. Текущая версия библиотеки хранится в “/external//trunk”. Все последовательные версии – в соответствующих метках “/external//version-x”. Проекты организованы аналогичным образом. Исходники (или бинарные файлы) библиотек копируются в каталог проекта, причём всегда копируется “trunk” нужной версии, а не одна из помеченных версий. Поскольку речь идет о копировании в понимании как это сделано в Subversion, такая схема позволяет относительно безболезненно мигрировать на новую версию библиотеки. Полный список преимуществ:

Переход на новую версию библиотеки происходит в три этапа:

В заключение добавлю, что помимо перечисленных достоинств, репозиторий не распухает от многочисленных копирований каталогов в силу особенностей реализации копирования в Subversion. Так что такую схему можно смело использовать для хранение больших библиотек.

comments powered by Disqus