Структура рабочего каталога для репозитория SVN Visual Studio

Question

Я только что представил SVN в нашей компании для наших проектов Visual Studio и создал репозиторий, который выглядит следующим образом («решение» - это решение Visual Studio, содержащее проекты 1..n):

/solution1/trunk/projectA/...
                /projectB/...
/solution2/trunk/projectC/...
/customerX/solution3/trunk/projectD/...
          /solution4/trunk/projectE/...
                          /projectF/...

Теперь у меня есть два варианта структурирования локальных рабочих каталогов:

Вариант A : позволить пользователю оформить каждое решение отдельно, используя AnkhSVN, что приведет к такой структуре:

/solution1/projectA/...
          /projectB/...
/solution2/projectC/...
/solution3/projectD/...
/solution4/projectE/...
          /projectF/...

или это, если я скажу пользователю вручную создать подкаталог customerX:

/solution1/projectA/...
          /projectB/...
/solution2/projectC/...
/customerX/solution3/projectD/...
/customerX/solution4/projectE/...
                    /projectF/...

Преимущество: пользователь может проверять только те решения, которые ему действительно необходимы. Недостаток: каждое решение должно быть проверено / обновлено отдельно.

Вариант B : попросить пользователя оформить весь репозиторий с помощью TortoiseSVN, что приведет к структуре, точно такой же, как в репозитории:

/solution1/trunk/projectA/...
                /projectB/...
/solution2/trunk/projectC/...
/customerX/solution3/trunk/projectD/...
          /solution4/trunk/projectE/...
                          /projectF/...

Преимущество: очень просто "обновить все svn". Недостаток: у пользователя также есть локальная копия всех веток и тегов.

---

ВОПРОС: Поскольку некоторые проекты совместно используются решениями (скажем, например, что projectA - это библиотека, которая также используется решением 3), нам нужно исправить одну структуру каталогов, чтобы убедиться, что относительные пути в файлах решений верны. Какой вариант вы рекомендуете и почему?

---

РЕДАКТИРОВАТЬ: Спасибо за все ваши прекрасные ответы, в частности за упоминание svn:externals и за подчеркивание важности хорошего дизайна хранилища. В итоге я обновил структуру репозитория :

/trunk/solution1/projectA/...
                /projectB/...
      /solution2/projectC/...
      /customerX/solution3/projectD/...
                          -svn:external to projectA
                /solution4/projectE/...
                          /projectF/...

, который гарантирует, что разработчик, работающий над решением3 только должен проверить решение3 (а не решение1) и решение может быть извлечено в любой каталог, т. Е. Рабочий каталог не нуждается в фиксированной структуре.

Answer 1

Хе-хе, это, вероятно, не очень полезно, но ... ни. :)

Я бы имел trunk на самом верхнем уровне, с проектами и решениями, организованными под этим рядом друг с другом в плоской структуре . Затем я использовал бы свойство svn:externals в каталогах решений, чтобы вставить соответствующие проекты в правильное место в рабочей копии каждого разработчика.

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

Кроме того, такой подход, предусматривающий использование одного ствола, значительно облегчает тегирование или разветвление всего репо, если вам когда-либо понадобится это.

Answer 2

Я бы настоятельно рекомендовал Филу Бутсу использовать плоскую структуру каталогов и использовать свойство svn:externals для включения общих проектов.

Основная причина заключается в том, что это дает вам возможность отделить процесс обновления различных клиентских проектов, использующих общий проект, например библиотеку. С вашей предложенной структурой есть только одна копия проекта общей библиотеки, используемая всеми другими клиентскими проектами: таким образом, все проекты, использующие общий проект, должны видеть ту же версию. Это не всегда желательно.

Иногда изменения в общей библиотеке требуют соответствующих изменений в клиентском коде, использующем эту библиотеку. В предложенной вами структуре такое изменение потребует от вас одновременного обновления всех клиентских проектов библиотеки или того факта, что многие клиентские проекты могут быть повреждены.

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

В итоге:

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

При svn:externals принятие изменения в проекте библиотеки влияет только на проект библиотеки. Каждому клиентскому проекту требуется дополнительная фиксация для обновления свойства svn:externals для ссылки на более новую версию библиотеки (которая может быть зафиксирована вместе с соответствующими изменениями в коде проекта клиента). Все клиентские проекты могут иметь обновления библиотеки, но они получают их только тогда, когда они явно запрашивают их.

Answer 3

Вариант A - вы не хотите каждый раз сносить весь репозиторий (все теги и ветви), и это будет стимулировать ваших пользователей думать о всем репозитории как о едином объекте, которым на самом деле это не вы хочу, чтобы они думали с точки зрения решений и разметки / ветвления в этом контексте.

Вы обращаетесь к общим проектам, ссылаясь на них как на внешние в «корне» соответствующих решений. Это будет означать, что один и тот же проект может появиться на жестком диске несколько раз, но это поддается управлению.

Здесь есть немного больше по этому вопросу: HowTo: Ссылка на внешние файлы SLN с TeamCity

Answer 4

Для чего это стоит, мы используем вариант B.

Мы также используем Tortoise SVN, а не Ankh SVN, потому что у нас есть немного лучшая гибкость со структурой нашего репозитория, если он не привязан к той же структуре каталогов, которую ожидает Visual Studio.

Первоначально я был категорически против этого, потому что мне понравилась интеграция IDE, которая была у меня с TFS, но после работы с ней в течение всего нескольких дней меня продали, что обмен большей гибкостью в тысячи раз важнее, чем интеграция с IDE.

Редактировать - Добавлено

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

У нас есть общая структура, подобная следующей:

\ Внутренние веб-приложения

\ Интернет-веб-приложения

\ Корпоративные приложения WinForms

\ Услуги для корпоративных вдов

\ Местоположение розничной торговли WinForms Apps

\ Розничные услуги определения местоположения

\ Shared

\ Файлы кросс-платформенного решения.

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

\Internet\<our company name>.com\Store Finder\Trunk

Важной частью этого является Shared, поскольку он содержит код, который используется во ВСЕХ других ветвях. Причина, по которой интеграция с IDE не работает для нас, заключается в том, что для этого нам понадобится решение на корневом уровне. Вместо этого у нас есть файлы Sln, где это уместно, и, поскольку у нас у всех есть полная копия репозитория, мы можем гарантировать, что относительные пути к любым проектам в каталоге \ Shared одинаковы на всех компьютерах разработчика.

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

Вам нужно потратить некоторое время, задавая вопросы типа «Если я выложу это как Y, смогу ли я сделать X?». Ваша ситуация будет уникальной для вашей команды и компании.