SVN и код совместно используются несколькими проектами

Лично я держу отдельный репозиторий, а затем использую атрибут [ http://svnbook.red-bean.com/en/1.0/ch07s03.html svn: externals].

SVN Externals позволяет вам ссылаться на другие репозитории (даже те, которые вы не запускаете, например, smarty subversion repo), когда вы запускаете svn update, ваш проект и внешний репозиторий будут обновлены.

с внешними SVN вы также можете ссылаться на конкретные ревизии, используя somethign, например, http://path-to-project.com/svn/thing -r1234 для выпусков и другие вещи, которые вам нужно сохранять статичными

Лучшая практика: всегда указывать ревизию, а затем обновлять номер ревизии внося изменения в разделяемую библиотеку, чтобы вы могли отслеживать ПОЧЕМУ вы обновили эти данные. также сохраняет все в здравом уме, когда вы помечаете или разветвляете основной проект.

Мы используем систему, аналогичную CWT: общий код, как правило, является самостоятельным проектом и, как таковой, существует отдельно в хранилище (или в отдельном хранилище). В рамках проекта, который использует внешние проекты (проект upstream ), мы включаем скомпилированные / упакованные двоичные файлы для проекта shared / downstream.

Таким образом, вышестоящий проект не будет отстрелен неожиданными изменениями в нижестоящих проектах.

Мы написали несколько сценариев для автоматического обновления основных проектов верхнего уровня новыми версиями этих двоичных файлов при необходимости (в противном случае это ручной процесс копирования пакета в соответствующие проекты, но это не так уж и сложно).

Недостаток, который мы до сих пор видели в этом методе madnes ^ W, заключается в том, что нижестоящие проекты, находящиеся на стадии очень активного развития (скажем, на ранних стадиях новой библиотеки), требуют того, что может показаться чрезмерным количество обновлений для вышестоящего проекта. Тестирование вышестоящего проекта может потребовать обновления разделяемой библиотеки, компиляции, копирования этого двоичного восходящего потока и компиляции / развертывания / любого другого вышестоящего проекта. Тем не менее, как только начальное безумие разработки библиотеки замедляется и библиотека становится несколько стабильной, эта «проблема» испаряется.

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

Моя рекомендация для работы с общим кодом (особенно с Java и .NET или библиотекой C / C ++) - использовать два набора репозиториев: один для исходного кода, а другой для контроля версий выпущенных изображений. Когда вы вносите изменения в «общий» проект, вы фиксируете свои исходные изменения в дереве исходных текстов, затем строите его и затем публикуете двоичные файлы, фиксируя их как новую ревизию в дереве релизов. Проекты, использующие «общий» проект, затем используют свойство svn: externals для добавления освобожденных двоичных файлов. Нет соблазна изменить локальные изображения общего кода. Если кто-то хочет изменить «общий» код, он делает это с помощью обычной практики разработки для этого проекта.

Подробнее см. В этом ответе на аналогичный вопрос.

Мы используем единую структуру репозитория, подобную этой:

/trunk/project1
/trunk/classlibrary (shared code)
/trunk/project2

В C # (который может быть другим языком), project1 и project2 включают ссылку на classlibrary. Когда мы строим (вот большое преимущество скомпилированной модели .NET), обнаруживаются любые несоответствия между собираемым проектом и class_library. Эти несоответствия устраняются до фиксации изменений. Используя серверный инструмент сборки (мы используем CruiseControl.NET), мы можем построить все проекты одновременно, что сообщит нам о любых проблемах.

Если ваш проект1 и проект2 не должны ссылаться на определенную версию библиотеки классов (чего мы избегаем , пытаясь заставить project1 и project2 всегда использовать последнюю версию class_library), это работает невероятно плавно.

Я стараюсь избегать создания отдельных репозиториев для связанных приложений. Поскольку class_library в приведенном выше примере связывает все эти вещи вместе, нет никаких преимуществ или логики в том, чтобы поддерживать ее в отдельных версиях, поскольку настоящая причина того, что она разделена на уровне проекта, заключается в том, что это общий код. Производственные приложения, которые используют общий код, делают это по определенной причине - они должны использовать одну и ту же версию общего кода, что означает, что они должны быть частью одной и той же ветви системы управления версиями.

Ответ, который отсутствует в вашем списке:

c) Всегда указывайте внешние элементы на определенную версию общего кода.

Это работает замечательно:

1. Вы всегда можете загрузите конкретную версию вашего проекта и гарантируйте сборку.
2. Ветвление и тегирование - это операция только на пути проекта.
3. Обновления общего кода могут быть сделаны для 1 проекта, но второй проект не получит их, пока не будет готов.
4. Когда второй проект принимает изменения, вы получаете событие, записанное в вашем стволе, в котором говорится, что оно было принято и почему.
5. Вы получаете возможность выпустить определенную версию библиотеки с определенными функциями для проекта. Это может помочь вам выбраться из дыр, если проект не готов к изменению API, но требует исправления ошибок и т. Д.

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

У вас есть два правильных ответа с двумя наборами недостатков.
Вот что я бы порекомендовал

Поместите ваш общий код в другой репозиторий, пометьте код версией выпуска Создайте svn externals в вашем магистральном каталоге, который указывает на ваш тег.

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

В качестве альтернативы попробуйте создать отдельный выпуск вашей библиотеки и ссылаться на библиотеку как на jar или lib / so.