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

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

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

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

Ответ 2

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

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

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

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

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