SVN общий код с внешними

Question

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

-trunk-Project1
      -Project2
      -Shared

Проект 1 и 2 имеют внешние для включения общего кода.Внешние указывают на конкретную ревизию, чтобы не нарушать сборку project2 при работе над project1 и общим кодом.Отсюда возникает проблема.

Когда вносится изменение в общий код, и я делаю коммит (с черепаховым SVN), изменения подхватываются как для проекта1, так и для общего кода и хорошо фиксируются в SVN как одна ревизия.Однако, когда я или коллега делает обновление, проект не будет собираться, потому что svn external указывает на «старую» ревизию.

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

Answer 1

Я думаю, у вас есть несколько вариантов.Первый - использовать один модуль с ветвями, как предлагает Мартин.У вас будет ветка для каждого активного проекта или для потока разработки.Изменения в совместно используемом коде будут обнаружены при слиянии обратно в транк.

например,

Module
    |
    + trunk
    |   + Project1
    |   + Project2
    |   + Shared
    |
    + branches
        |
        + Project1Development
        |    + Project1 [active development here]
        |    + Project2 
        |    + Shared [active development here]
        |
        + Project2Development
             + Project1 
             + Project2 [active development here]
             + Shared [active development here] 

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

Project1
    |
    + trunk [svn:external to a branch of Shared]

Project2
    |
    + trunk [svn:external to a branch of Shared]

Shared
    |
    + trunk
    |
    + branches
        |
        + Project1Development
        |
        + Project2Development

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

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

Answer 2

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

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

Я могу порекомендовать Бумага Хенрика Книберга о контроле версий , она хорошо освещает эту тему.

Answer 3

Пока все хорошие ответы - но есть и другой вариант: использовать теги. Когда разработка завершится, вы захотите снова связать внешние элементы с P1 и P2, которые указывают на новый общий проект. До этого момента вы хотите, чтобы P1 и P2 указывали на старую известную рабочую версию Shared.

Итак, продолжайте работу над внешней магистралью, указывающей на общую версию HEAD. когда вы закончите, разветвите весь лот в каталог тегов (например, назовите его ReleaseX), который будет содержать рабочий код для всех этих версий. тогда вы можете продолжить работу над транком, не беспокоясь о том, что вы нарушаете «готовую» версию, которую вы выпустили.

Если вы выпускаете P1 и P2 в разное время, вы все равно можете использовать этот подход - когда вы помещаете проект в ветвь тегов, вы устанавливаете его внешние параметры для текущей версии общего проекта. Когда следующий проект будет помечен (и проект Shared будет обновлен), старый проект будет по-прежнему указывать на правильную версию Shared, пока его следующий выпуск не будет помечен и т. Д.

Answer 4

Ваша проблема в том, что Project1 и Project 2 требуют определенных версий Shared. Так что вам нужно сделать это в вашей раскладке.

Например, вы можете сделать это:

-trunk - Проект 1 - Project1Share - Проект 2 - Project2Share - Общий

И пусть Project1Share и Project2Share являются внешними версиями с указанием версий конкретного Shared, а «Shared» является последней версией кода этой совместно используемой библиотеки.

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

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

Если правило состоит в том, что Project1 всегда строится с использованием последней версии shared, а project2 - с использованием определенных версий, то внешняя версия project1shared может быть неверсированной, а версия project2 - версионной.