Лучшая стратегия для ветвления кода SVN и поддержки ссылок на проекты Visual Studio

Question

У нас есть основной визуальный студийный проект, хранящийся в SVN с использованием стандартной структуры trunk / branch / tags. Однако этот проект ссылается на внешние проекты вне этой структуры, поэтому, когда мы создаем ветвь кода, все ссылки на проекты exteranl терпят неудачу, поскольку они находятся на одном уровне.

т. trunk / MyProjectCode становится branch / MyFeatureBranch / MyProjectCode после ветвления, и поэтому из-за этого дополнительного уровня иерархии любые ссылки на внешние проекты терпят неудачу.

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

Answer 1

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

svn co svn://server/project/trunk project
svn co svn://server/project/branches/MyFeatureBranch project-feature

Таким образом, у вас будет две директории рядом с именами project и project-feature. Это должно избежать проблем с различной глубиной каталогов и относительными путями.

Answer 2

Мы разветвляем все, что относится к этому продукту. Таким образом, если есть 5 проектов, которые являются его частью, мы разветвляем все 5 проектов, чтобы убедиться, что у нас есть полная копия того, что эта ветвь собирается использовать. Если у вас есть проблемы с путями, вы можете проверить программу под названием Junction .

Answer 3

У нас была такая же проблема, и я подумал о том, чтобы редактировать файлы .sln и .csproj, заменяя относительные пути на абсолютные. Я был немного обеспокоен этим, поскольку VS поддерживает эти файлы и что мешает ему отменить это и вернуться к относительным путям в некоторый момент в будущем (когда разработчик сохраняет проект и регистрирует его, например).

Этим утром у меня был «момент ясности» в моей поездке: несмотря на то, что мы храним ветку в отдельной папке ветвей, почему я должен проверить ее в одной?

так, вместо:

C:
 |_ svnworkarea
       |_ project
           |_ branches
               |_ project-feature
                       |_ source etc

           |_ trunk
               |_ source etc

Теперь у меня есть:

C:
 |_ svnworkarea
    |_ project
         |_ project-feature
               |_ source etc

         |_ trunk
               |_ source etc

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

Answer 4

То, что я делал в прошлом, для магазина разработки, разрабатывающего много проектов и много общих ссылок, заключалось в том, чтобы хранить внешние ссылки в общем месте. Это может быть общий сетевой ресурс или согласованное (абсолютное) местоположение, которое каждый имеет на своем жестком диске (структурированный как C: \ SharedLibs \ Library \ Version). Мы хранили общие папки в отдельном svn-хранилище, которое каждый должен был зайти в эту папку SharedLibs, и настроили наши ссылки на этот абсолютный путь.

Другая стратегия, которую я применил, заключается в том, что вы также найдете во многих проектах с открытым исходным кодом: просто храните ссылки вместе с вашим проектом. Например. Вы могли бы иметь транк с подпапками src (для исходного кода) и lib (для внешних ссылок). Вероятно, это лучшая практика: все, что вам нужно сделать, чтобы собрать проект (будь то ствол или ветка), это проверить его и запустить инструмент сборки.

Еще одним вариантом является использование свойства svn: externals. С помощью этого свойства вы можете убедиться, что файлы из других мест в вашем хранилище (или из других хранилищ) извлекаются вместе с вашим проектом. По опыту, я не рекомендую это, но это вариант. Читайте об этом в svn book: http://svnbook.red -bean.com / ru / 1.5 / svn.advanced.externals.html