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

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

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

12 svn
19.08.2008 03:03:30
Вот как я это сделал. Я также беспокоился о том, как я создал хранилище, но, похоже, он работает для нас. < stackoverflow.com/questions/16829/… >
Monroecheeseman 25.08.2008 12:20:12
Название этого вопроса действительно должно быть изменено на первое предложение. Вы не можете сказать, в чем вопрос, пока не начнете читать более подробное описание.
Bob Cross 20.09.2008 18:55:51
6 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

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

4
19.08.2008 03:33:39

Репозитории Subversion обычно подразделяются на:

branch/
tags/
trunk/

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

branch/
tags/
trunk/
    project1/
    project2/

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

project1/
    branch/
    tags/
    trunk/

project2/
    branch/
    tags/
    trunk/

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

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

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

9
19.08.2008 03:28:14

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

Решение
проекта 1

  • Ветвь
  • Теги
  • Хобот

Проект 2

  • Ветвь
  • Теги
  • Хобот

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

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

  • Ветвь
  • Теги
  • Хобот
  • Документы (необязательно)
0
19.08.2008 03:22:18

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

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

0
19.08.2008 04:16:12

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

0
19.08.2008 12:53:28
После того, как вы поняли, что у вас есть время, чтобы все уладилось, как это изменение повлияло на ваше решение проблемы? Это работает хорошо для вас?
Dean Poulin 12.03.2009 15:50:12

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

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

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

0
21.08.2008 09:59:45