Subversion: как организовать теги svn для решений Visual Studio или как создать версию всего решения VS

В моем репозитории Subversion для решения Visual Studio есть следующие каталоги:

  • ProjectName
    • tags
    • ветви
    • trunk
      • MySolution.sln
      • MyProject1 (реж)
      • MyProject2 (реж)

Если я обновляю MyProject1 с версии 1.0.0 до 2.0.0, нужно ли копировать все из магистрали в новый каталог под тегами, или мне следует скопировать все, что находится в trunk / MyProject1, в новый каталог под тегами?

И, если первое - правильный способ сделать что-то, как мне создать версию всего решения Visual Studio?

Спасибо.


person ken    schedule 18.01.2012    source источник


Ответы (1)


Ознакомьтесь с руководством по svn, чтобы понять основные концепции управления версиями.

Trunk является основным направлением разработки, поэтому вы можете обновиться с версии 1.0.0 до 1.0.1, 2.0.0 и т. д.

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

Тег - это моментальный снимок вашего ствола или ответвления в определенный момент времени.

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

Сначала вы можете скопировать ProjectName на свой локальный диск, например c: \ working \ ProjectName. Таким образом, у вас есть первая локальная структура:

  • ProjectName
    • tags
    • ветви
    • trunk
      • MySolution.sln
      • MyProject1 (реж)
      • MyProject2 (реж)

Когда вы достигнете своего тега выпуска 1.0.0.0, он будет иметь такую ​​структуру:

  • ProjectName
    • tags
      • 1.0.0.0
        • MySolution.sln
        • MyProject1 (реж)
        • MyProject2 (реж)
    • ветви
    • trunk
      • MySolution.sln
      • MyProject1 (реж)
      • MyProject2 (реж)

Затем обновитесь до 2.0.0.0 и так далее:

  • ProjectName
    • tags
      • 1.0.0.0
        • MySolution.sln
        • MyProject1 (реж)
        • MyProject2 (реж)
      • 2.0.0.0
        • MySolution.sln
        • MyProject1 (реж)
        • MyProject2 (реж)
    • ветви
    • trunk
      • MySolution.sln
      • MyProject1 (реж)
      • MyProject2 (реж)

В любое время вы можете работать над основной веткой или выпуском 1 или 2 (возможно, для отладки или применения патчей)

person Be.St.    schedule 19.01.2012
comment
Я думал, что получу такой ответ. Итак, я должен включить MyProject2 в тег, даже если он вообще не изменился. - person ken; 19.01.2012
comment
Вы должны думать о своем решении в целом. Таким образом, вы помечаете все решение, а не только MyProject2. И не волнуйтесь, это не пустая трата места, потому что тег - это всего лишь ссылка на конкретную ревизию. Код не дублируется. - person Be.St.; 19.01.2012
comment
Что меня немного беспокоит в этом методе, так это то, что схема именования тегов становится произвольной. Я знаю версию живой библиотеки MyProject2, потому что номер версии встроен в сборку. Но у меня нет простого способа соотнести эту версию сборки с тегом svn, потому что версия тега svn является произвольной и не имеет корреляции с версией сборки. Ну что ж... - person ken; 19.01.2012
comment
Хорошо, это другая проблема и требует более 500 символов комментария :-) Вы правы, очень важно синхронизировать версию сборки с ревизией svn (ревизия SVN - это порядковый номер, увеличивающийся при каждой фиксации). У этой проблемы есть разные решения (от самого простого до сложного). 1 - в небольшой команде разработчиков вы можете получить номер следующей версии SVN и изменить AssemblyVersion перед фиксацией. 2 - вы можете использовать MSBuildTask для автоматизации вышеуказанного процесса 3 - вы можете добавить непрерывный сервер в жизненный цикл вашего программного обеспечения, чтобы автоматически пометить вашу версию SVN - person Be.St.; 19.01.2012