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

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

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

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

для чего это стоит, мы используем опцию B.

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

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

Edit-Добавлено

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

у нас есть общая структура следующим образом:

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

\Веб-Приложений

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

\Корпоративные Услуги Вдов

\Retail Location WinForms Apps

\Retail Location Services

\Shared

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

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

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

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

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

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

Я бы сильно поддержал решение Phil Booths об использовании плоской структуры каталогов и использовании svn:externals свойство include общие проекты.

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

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

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

в итоге:

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

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