Лучший способ структурировать хранилище в Subversion для проектов Visual Studio?

Question

У меня есть несколько проектов на C # .dll, которые являются общими для многих приложений. В настоящее время у меня есть один большой репозиторий. У меня каждая DLL хранится как отдельный проект в хранилище, и каждый проект приложения хранится как проект в том же хранилище.

Недавно я переключился на Subversion для управления исходным кодом, и я боюсь, что я не справился с задачей структурирования хранилища. Я хотел бы услышать, что делают другие.

Answer 1

Репозитории Subversion, как правило, подразделяются на:

branch/
tags/
trunk/

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

branch/
tags/
trunk/
    project1/
    project2/

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

project1/
    branch/
    tags/
    trunk/

project2/
    branch/
    tags/
    trunk/

Обратите внимание, что эта практика - просто соглашение, и ничто в SVN не требует (или действительно поощряет) делать это именно так. Тем не менее, все привыкли к этому. Таким образом, вы сделаете людям одолжение.

Чтобы уточнить, ствол - это место, где будет проходить ваше основное развитие. Если вы хотите пометить определенную ревизию (например, версию выпуска), просто svn скопируйте проект в каталог тегов. Кроме того, просто скопируйте код в каталог branch , если вы хотите сделать что-то драматическое или продолжительное и не хотите препятствовать прогрессу в trunk . Позже вы можете svn объединить свою ветку обратно в ствол , когда она будет готова к действию!

Если вы хотите исправить ошибки в вашем текущем хранилище Subverion, просто используйте svn move , чтобы переместить их. В отличие от процесса удаления и добавления CVS , перемещение сохранит историю версий для нового местоположения.

Answer 2

использование структуры репозитория branch / trunk / tag довольно стандартно, но если я вас правильно понимаю, ваша проблема в том, что у вас есть набор общих dll-проектов, которые используются в нескольких проектах. Это может определенно стать сложным для управления.

Таким образом, типичный сценарий здесь заключается в том, что у вас есть библиотека классов с именем Common.Helpers, в которой есть код, общий для всех ваших приложений.

Допустим, я запускаю новое приложение под названием StackOverflow.Web, которое должно ссылаться на Common.Helpers.

Обычно вам нужно создать новый файл решения и добавить новый проект с именем Stackoverflow.Web, добавить существующий проект Common.Helpers и затем сослаться на него из нового проекта Stackoverflow.Web.

Обычно я пытаюсь создать репозиторий для проекта Common.Helpers, а затем в subversion ссылаться на него как external . Таким образом, вы можете хранить код под контролем исходного кода в одном месте, но при этом использовать его отдельно в нескольких проектах.

Answer 3

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

Отслеживаемое слияние (как и коммит) всегда выполняется над каталогом и его дочерними элементами.

То же правило применяется к атомным коммитам. (Работает стабильно только в пределах одной рабочей копии. Может работать в некоторых других конкретных случаях, но такое поведение не гарантируется)

Answer 4

Спасибо всем, кто ответил. lomaxx, я провел утро, изучая использование внешней функции, и похоже, что это путь. Я не знал об этом, вероятно, потому что это не совсем заметно в черепахе.

Answer 5

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

У JP Boodhoo есть отличная серия на тему автоматических сборок, структуры папок VS и ускорения работы разработчиков.

Answer 6

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

Решение
Проект 1

• Филиал
• Метки
• Багажник

Проект 2

• Филиал
• Метки
• Багажник

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

В остальном наиболее распространенная структура:

• Филиал
• Метки
• Багажник
• Документы (необязательно)