Подверсия и совместно используемые файлы через репозитории/проекты?

Я не знаю, что именно вы слышали о SVN: Externals, но я думаю, что это то, что вы должны использовать здесь. Вы можете даже указать свой внешний источник, чтобы он указывал на стабильную ветку или тег выпуска вашего общего источника, или даже указывать на два разных тега из двух других проектов, которые его используют (это может понадобиться, если вы исправите ошибку в общем коде как можно скорее) для проекта A, но у вас нет достаточно времени, чтобы полностью протестировать его с проектом B).

Худшее, что вы можете сделать, это ваш вариант 3 (перекрестное обновление двух версий одних и тех же файлов).

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

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

Наличие того же файла в двух проектах, даже с исходным управлением напрашивается на неприятности рано или поздно!

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

Включить общий подпроект

Внешние товары

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

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

• /
  • соединительная линия
    <литий> prj1 <литий> prj2 <литий>, совместно использованный теги
  • <литий> <литий> tag1
    prj1 <литий>, совместно использованный

таким образом, когда Вы хотите отметить prj1, Вы создаете tag1, затем копируете prj1 и совместно использованный в него.

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

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

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

Я поместил этот код в третий репозиторий, а затем периодически переносил этот код в свои зависимые репозитории проектов в качестве внутренних этапов выпуска и обновления; Мои отдельные проекты затем имеют ревизию, которая выглядит как «Обновленный до версии 4.3.345 Shared.App.dll», которая включает в себя все изменения, необходимые для работы с этой версией.

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

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

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

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

Как другие, я, конечно, сделал бы это последний путь. То, что делает Вы чувствуете, неправильно с наличием 'всего' одного репозитория? Репозиторий о правах администратора. Кроме этого, я видел бы, что единственный repo имеет любое количество N проектов в нем.