У меня есть несколько проектов C# .dll
, общих для многих приложений. В настоящее время у меня есть одно большое хранилище. У меня каждая DLL хранится как отдельный проект в репозитории, а каждый проект приложения хранится как проект в том же репозитории.
Я недавно перешел на Subversion для управления версиями и боюсь, что плохо структурировал репозиторий. Я хотел бы услышать, что делают другие.
Вот как я это сделал. Я также беспокоился о том, как я создал репозиторий, но, похоже, он работает на нас. stackoverflow.com/questions/16829/…>
Репозитории Subversion обычно подразделяются на:
branch/
tags/
trunk/
Вы бы либо поместили все свои проекты DLL и приложений в хобот, а затем при необходимости использовали бы ответвляться и теги для всех из них:
branch/
tags/
trunk/
project1/
project2/
В качестве альтернативы вы можете создать папки для каждого проекта в корне, а затем поместить в них общие ветки, теги и магистральные папки.
project1/
branch/
tags/
trunk/
project2/
branch/
tags/
trunk/
Обратите внимание, что это просто соглашение, и ничто в SVN не требует (и не способствует) именно таким образом. Однако все к этому привыкли. Таким образом, вы окажете людям услугу, если согласитесь.
Если уточнить, хобот - это то место, где будет происходить ваша основная разработка. Если вы хотите отметить конкретную ревизию (например, версию выпуска), просто svnкопировать проект в каталог тегов. Кроме того, просто скопируйте код в каталог ответвляться, если вы хотите сделать что-то драматическое или продолжительное и не хотите препятствовать прогрессу в хобот. Позже вы можете svnслить ваш ответвляться обратно в хобот, когда он будет готов к действию!
Если вы хотите исправить ошибки в текущем репозитории Subverion, просто используйте svnдвигаться, чтобы переместить их. В отличие от процесса удаления и добавления CVS, при перемещении будет сохранена история версий для нового местоположения.
если ваши подпроекты могут быть выпущены в разных версиях (например, элементы управления, веб-части и т. д.), тогда может иметь смысл построить вашу структуру следующим образом:
Решение
Проект 1
- Branch
- Tags
- Trunk
Проект 2
- Branch
- Tags
- Trunk
Таким образом, вы можете управлять каждой версией проекта независимо.
В остальном наиболее распространенная структура:
- Branch
- Tags
- Trunk
- Docs (Optional)
использование структуры репозитория ветка / ствол / тег довольно стандартно, но, если я правильно вас понимаю, ваша проблема в том, что у вас есть набор общих проектов dll, которые используются в нескольких проектах. Это определенно может стать сложным в управлении.
Итак, типичный сценарий здесь состоит в том, что у вас есть некоторая библиотека классов с именем Common.Helpers, код которой является общим для всех ваших приложений.
Допустим, я запускаю новое приложение под названием StackOverflow.Web, которое должно ссылаться на Common.Helpers.
Обычно вы создаете новый файл решения и добавляете новый проект с именем Stackoverflow.Web, добавляете существующий проект Common.Helpers, а затем ссылаетесь на него из нового проекта Stackoverflow.Web.
Обычно я пытаюсь создать репозиторий для проекта Common.Helpers, а затем в Subversion сослаться на него как на внешний. Таким образом, вы можете держать код под контролем источника в одном месте, но при этом использовать его отдельно в нескольких проектах.
Я сохраняю все в репозитории, чтобы разработчикам (или перестроенным devboxes) было легко выполнить извлечение из SVN, а затем запустить сборку (со всеми необходимыми сборками в относительных путях). Если у вас есть несколько проектов, которые должны быть отдельными, это также побудит команду ваших общих компонентов создавать высококачественные сборки. Это может последовать за нормальным менталитетом выпуска в производство, когда совместно используемая сборка будет обновляться в ваших последующих проектах. Это очень естественный Цепочка создания стоимости программного обеспечения, за счет небольшого дискового пространства.
У JP Boodhoo есть отличная серия по теме автоматизированных сборок, структуры папок VS и быстрого запуска разработчиков.
Спасибо всем, кто ответил. lomaxx, я провел утро, изучая использование внешней функции, и похоже, что это выход. Я не знал об этом, вероятно, потому, что это не совсем заметно у черепахи.
Увидев, что у вас было время, чтобы решить эту проблему, как это изменение повлияло на ваше решение проблемы? У вас это хорошо работает?
Если вы хотите использовать отслеживание слияния Subversion 1.5 для нескольких проектов одновременно, вам следует использовать одно дерево без внешних элементов.
Отслеживаемое слияние (как и фиксация) всегда выполняется над каталогом и его дочерними элементами.
То же правило применяется к атомарным коммитам. (Работает стабильно только в пределах одной рабочей копии. Может работать и в некоторых других случаях, но такое поведение не гарантируется)
Название этого вопроса действительно следует изменить на первое предложение. Вы не сможете понять, в чем заключается вопрос, пока не начнете читать более подробное описание.