У меня есть несколько проектов С# .dll, которые являются общими для многих приложений. В настоящее время у меня есть один большой репозиторий. У меня есть каждая DLL, хранящаяся как отдельный проект в репозитории, и каждый проект приложения, сохраненный как проект в том же репозитории.
Недавно я переключился на Subversion для управления версиями, и я боюсь, что я не очень хорошо структурировал репозиторий. Я хотел бы услышать, что делают другие.
используя структуру репозитория ветки/магистрали/тега, довольно стандартно, но если я правильно понимаю вас, проблема заключается в том, что у вас есть набор общих проектов dll, которые используются в нескольких проектах. Это может стать сложным для управления.
Итак, типичный сценарий здесь состоит в том, что у вас есть библиотека классов, называемая Common.Helpers, которая имеет код, общий для всех ваших приложений.
Скажем, я запускаю новое приложение под названием StackOverflow.Web, которое должно ссылаться на Common.Helpers.
Обычно вам нужно создать новый файл решения и добавить новый проект Stackoverflow.Web и добавить существующий проект Common.Helpers, а затем ссылаться на него из нового проекта Stackoverflow.Web.
То, что я обычно пытаюсь сделать, это создать репозиторий для проекта Common.Helpers, а затем в subversion указать его как external. Таким образом, вы можете сохранить код под контролем источника в одном месте, но все равно использовать его отдельно в нескольких проектах.
Репозитории Subversion обычно подразделяются на:
branch/
tags/
trunk/
Вы либо разместите все свои проекты DLL и приложений в туловище, а затем используйте ветвь и теги для всех них по мере необходимости тоже:
branch/
tags/
trunk/
project1/
project2/
В качестве альтернативы вы можете создавать папки для каждого проекта в корне, а затем размещать в них общие ветки, теги и папки соединительных линий.
project1/
branch/
tags/
trunk/
project2/
branch/
tags/
trunk/
Обратите внимание, что эта практика является просто конвенцией, и ничто в SVN не требует (или действительно продвигает) выполнения именно этого. Однако к нему привыкли все. Таким образом, вы будете делать людям услугу, чтобы идти вперед.
Чтобы подробнее остановиться, туловище - это место, где будет происходить ваше основное развитие. Если вы хотите пометить конкретную ревизию (например, версию выпуска), просто svn скопировать проект в каталог тегов. Кроме того, просто скопируйте код в каталог branch, если вы хотите сделать что-то драматическое или продолжительное и не хотите препятствовать прогрессу в туловище. Позже вы можете svn объединить свою ветвь обратно в туловище, когда она готова к действию!
Если вы хотите исправить ошибки в вашем текущем репозитории Subverion, просто используйте svn move, чтобы переместить их. В отличие от процесса удаления и добавления CVS, перемещение сохранит историю версий для нового местоположения.
если ваши субпроекты могут быть выпущены в разных версиях (например, элементы управления, веб-части и т.д.), тогда может возникнуть смысл построить вашу структуру следующим образом:
Решение
Проект 1
- Филиал
- Теги
- Trunk
Проект 2
- Филиал
- Теги
- Trunk
Таким образом вы можете самостоятельно управлять каждой версией проекта.
В противном случае наиболее распространенная структура:
- Филиал
- Теги
- Trunk
- Документы (необязательно)
Я храню все в репозитории, чтобы упростить разработчикам (или перестроить devboxes) возможность выписки из SVN, а затем запустить сборку (со всеми необходимыми сборками в относительных путях). Если у вас есть несколько проектов, которые должны быть отдельными, это также побуждает команду ваших общих компонентов предоставлять высококачественные сборки. Это могло бы следовать нормальному выпуску в производственный менталитет, где общий сборник будет обновляться в ваших проектах вниз по течению. Это очень естественная Software Value Chain, за счет небольшого дискового пространства.
JP Boodhoo отличная серия на тему автоматизированных сборок, структуры папок VS и быстрого запуска разработчиков.
Спасибо всем, кто ответил. lomaxx, я потратил утро на использование внешней функции, и похоже, что это путь. Я не знал об этом, вероятно, потому, что он не очень заметен в Черепахе.
Если вы хотите использовать отслеживание слияния Subversion 1.5 по нескольким проектам одновременно, вы должны использовать одно дерево без внешних.
Отслеживание слияния (как и фиксация) всегда над каталогом и его дочерними элементами.
То же правило применяется к атомным коммитам. (Работает только стабильно в пределах одной рабочей копии. Он может работать в некоторых конкретных случаях, но это поведение не гарантируется)