Subversion и общие файлы в репозиториях / проектах? - PullRequest
25 голосов
/ 25 сентября 2008

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

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

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

  • Используйте внешний или внешний или любой другой для SVN. Я слышал, что это не очень хороший вариант по разным причинам

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

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

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

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

Есть еще комментарии?

Ответы [ 8 ]

9 голосов
/ 25 сентября 2008

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

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

6 голосов
/ 25 сентября 2008

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

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

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

4 голосов
/ 17 марта 2011

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

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

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

2 голосов
/ 25 сентября 2008

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

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

  • /
    • Ствол
      • prj1
      • prj2
      • Общий
    • теги
      • tag1
        • prj1
        • Общий

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

1 голос
/ 26 сентября 2008

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

1 голос
/ 25 сентября 2008

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

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

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

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

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

0 голосов
/ 25 сентября 2008

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

Как и другие, я бы точно так и сделал. Что, по вашему мнению, не так с «одним» хранилищем? Репозиторий о правах администратора. Кроме этого, я бы увидел, что в одном репо содержится N проектов.

0 голосов
/ 25 сентября 2008

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...