SVN и код разделены между несколькими проектами

Question

У меня есть несколько проектов в SVN. Каждый из этих проектов находится в своем стволе и разветвляется для релизов.

И есть общий код, который используется в каждом проекте. Вопрос в том, как лучше всего обращаться с кодом.

Позвольте мне привести несколько сценариев и связанных с ними вопросов

a) Поместите общий код в отдельную магистраль (или хранилище) и используйте svn: external.

В случае, если мы разветвим некоторые проекты, возникнут две проблемы:

• Любая модификация разделяемого кода, которая выполняется в транке, будет распространяться на ветку, потому что svn: external примет изменения
• В случае, если нам потребуется в какой-то момент вернуться и собрать именно тот код, который был собран для выпуска, нам будет сложно получить точный код, потому что snv: external снова подберет последнюю копию общего кода вместо кода в тот момент, когда проект был удручён.

Как я понимаю, есть одна работа вокруг. Как только мы разветвляемся, мы можем изменить svn: external, чтобы получить точную версию общего кода. Тем не менее, опять есть две ловушки:

• Вы должны помнить, чтобы делать это каждый раз, когда вы переходите. (Я ненавижу такие вещи, которые легко забыть).
• Вы не можете изменять общий код, если вам нужно сделать исправление для разветвленного / выпущенного проекта.

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

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

Я что-то упустил? Есть ли разумный способ справиться с этим?

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

Мы используем единую структуру хранилища, например:

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

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

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

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

Answer 5

Ответ, которого нет в вашем списке:

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

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

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

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

Answer 6

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

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