структура папок svn - PullRequest
       84

структура папок svn

1 голос
/ 22 сентября 2010

За последние несколько месяцев одно из моих веб-приложений выросло из одного файла проекта и включает в себя несколько библиотек классов. Структура SVN вроде органично выросла и выглядит примерно так:

repository-root
    site1
        trunk
        tags

    site2
        trunk
        tags

    library1
        trunk   
        tags
        ...

    library2
        trunk

Теперь, когда развитие набирает обороты, я бы хотел что-то вроде этого

repository-root
    site1
        trunk
        tags
           release-20100922
             site1
             library1
             library2
             ...
           release-20110101
             ...

Теперь, поскольку Site1 и Site2 оба ссылаются на библиотеки классов library1 и library2, каков наилучший способ реорганизации структур папок, чтобы

  • Теги каждого сайта содержат замороженную копию связанных библиотек классов на момент создания тега сайта, и
  • Каждый сайт по-прежнему может ссылаться на библиотеки классов без необходимости иметь отдельную копию в стволе каждого сайта

Возможно, я просто думаю об этом неправильно. Предложения?

Ответы [ 3 ]

5 голосов
/ 23 сентября 2010

svn: внешние как "мягкая линия управления источником" в модульных приложениях.

svn: externals может помочь вам избежать некоторых ручных задач и дать четкое представление о том, что есть (и в какой версии).

У вас есть несколько «независимых» продуктов, называемых «сайтами», которые полагаются на библиотеки. Вы получили повторные циклы для ваших продуктов и для ваших библиотек. Для повышения стабильности вам может не потребоваться работать с кодом магистральной библиотеки где-либо, поскольку он может нарушить работу не только одного, но и нескольких сайтов. С другой стороны, в более гибких подходах «ранний перерыв, частый перерыв» может быть желательным. Поэтому выбор версии библиотеки для использования в основной разработке был бы плюсом.

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

Я бы предложил следующий формат:

repository-root
    site1
        trunk (active development, unstable)
             mycode
             library1 -> external of "library1/tags/2.0"
        branches
            2-branch (maintenance, stable)
                mycode
                library1 -> external of "library/tags/1.0"
        tags
            2.0.0
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.1
                mycode
                library1 -> external of "library/tags/1.0"
    library1
        trunk   
        tags
            1.0
            2.0
            ...

Нет необходимости объединять или перемещать исходный код библиотеки, когда вы передумаете и решите: «Эй, использование нового API библиотеки 2.0 в нашей магистрали было делом легким, возможно, нам стоит использовать магистраль в будущем».

Давайте представим, что в "library1 1.0" есть ошибка, поэтому вы выпускаете "library1 1.1". Вам также нужно будет сделать новый выпуск исправлений для вашего основного приложения и отправить его. поэтому вы обновляете ветку обслуживания «site1 2.0», тестируете и создаете тег.

repository-root
    site1
        trunk (active development, unstable)
             mycode
             library1 -> external of "library1/tags/2.0"
        branches
            2-branch (maintenance, stable)
                mycode
                library1 -> external of "library/tags/1.1" (changed the property)
        tags
            2.0.0
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.1
                mycode
                library1 -> external of "library/tags/1.0"
            2.0.2
                mycode
                library1 -> external of "library/tags/1.1" (inherits property change)
    library1
        trunk   
        tags
            1.0
            1.1
            2.0
            ...

Внешние устройства гарантируют, что у ВАС есть выбор относительно того, какие изменения библиотеки вы хотите включить и КОГДА вы этого хотите. Это поможет уменьшить «сюрпризы».

Имейте в виду, что svn: externals замедляет ваши команды "svn update" с каждым внешним, который должен быть проверен. Код находится в стадии разработки, чтобы улучшить это.

Посетите публичный репозиторий Silverstripe, чтобы узнать, как они работают. Хорошо работает для них.

svn propget svn:externals http://svn.silverstripe.com/open/phpinstaller/tags/2.4.2/

Надеюсь, что смогу помочь

1 голос
/ 22 сентября 2010

У меня была похожая проблема, и я решил ее, используя следующую структуру хранилища:

repository-root
    trunk
        site1
        site2
        library1
        library2
    tags
        site1
            release-20100922
                site1
                site2
                library1
                library2
        site2
            release-20110101
                site1
                site2
                library1
                library2

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

Да, для выпуска сайта1 я тоже отметил сайт2. Но с тегами subversion стоит дешево.

1 голос
/ 22 сентября 2010

Не делая ничего особенного, возможная структура каталогов Subversion может выглядеть так:

repository-root
    site1
        trunk
        tags
            release-20100922
                site1
    site2
        trunk
        tags

    library1
        trunk   
        tags
            release-20100922
                library1

    library2
        trunk   
        tags
            release-20100922
                library2

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

Где-то под тегом site1 release-20100922 у вас может быть текстовый файл со списком библиотек, включенных в выпуск.

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

...