Subversion и общие файлы в репозиториях/проектах?

Я переношу клиентский репозиторий SourceSafe (3 проекта) в SVN, а два из проектов совместно используют исходные файлы. (Эти проекты представляют собой отдельные продукты - с разными названиями и версиями выпуска и т.д.)

Сработал ли SVN этот недостаток? Как люди обычно справляются с этим сценарием?

Из опций, которые я знаю о/может думать о

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

Я, вероятно, перейду к последней опции.

Любые другие комментарии?

Ответ 1

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

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

Ответ 2

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

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

Имея тот же файл в двух проектах, даже с контролем soruce рано или поздно возникает проблема!

Ответ 3

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

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

Внешние элементы

Ответ 4

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

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

/
- Ствол
  - prj1
  - prj2
  - общие
- теги
  - tag1
    - prj1
    - общие

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

Ответ 5

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

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

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

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

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

Ответ 6

Вы не указываете, какой язык или инструмент сборки вы используете, но для проектов Java Maven, возможно, стоит изучить. Одна из особенностей заключается в том, что по существу расширяет ant, чтобы вы могли задействовать внешние зависимости. Это избавляет вас от необходимости создавать, поддерживать и маркировать метапроект. Он также позволяет либо вытащить из HEAD внешнего проекта, либо вытащить из данного тега, что избавляет одну из проблем от предыдущего плаката о совместном использовании общих файлов между проектами и непреднамеренно причиняет поломку, поскольку вы можете контролировать, когда каждый проект использует более новую версию разделяемых файлов независимо.

Ответ 7

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

Ответ 8

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

Как и другие, я бы наверняка сделал это последним путем. Что вы считаете неправильным, имея "только" один репозиторий? Репозиторий - это права администратора. Кроме этого, я бы увидел, что в одном репо есть N проектов.