В SVN, как поддерживать общую кодовую базу, которая будет изменена двумя или более проектами?

Question

Этот вопрос в некотором смысле относится к «Лучший способ поделиться общим кодом» , но в этом случае ситуация немного отличается.

Сейчас я пишу приложение, скажем, A, для проекта. Он не завершен, и теперь будет запущен новый проект B, который в основном является копией A с надстройками. Поскольку оба проекта не завершены, вполне вероятно, что у меня будут исправления в A, которые мне нужно перенести в B; и, возможно, улучшения в B, которые я тоже хотел бы перенести на A.

Как мне использовать SVN для моей ситуации?

Answer 1

Если они действительно очень похожи, я бы просто создал ветку в репозитории проекта А для проекта Б, а затем объединил бы по мере необходимости.

В противном случае извлеките общий код в его собственное новое хранилище и используйте svn:externals для ссылки на него в каждом проекте.

Answer 2

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

Если вы хотите отделить код, ваши варианты:

• Поместите все в один репозиторий с каталогами верхнего уровня для каждого проекта (A, B, shared) или
• Создайте два репо, A и B, используйте svn:externals для третьего репо с общим кодом, где у вас есть ветви для A и B (при необходимости), чтобы вы могли легко объединить оба.

Попытка сохранить отдельные версии в каждом репо - это путь к катастрофе, если этот код изменяется независимо в обоих проектах. Объединение между разными репозиториями вообще не поддерживается, поэтому не ходите туда. (Поверь мне. Я был там.)

Answer 3

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

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