Структура проектов в управлении версиями - конкретная.NET

Если Ваши TTB распространены, а не на проект, нет никакой проблемы с ним. Или я пропускаю что-то?

Мы пошли с очень упрощенным подходом:

Файловая структура:

• Папка решения (содержит файл решения, сценарии сборки, возможно, больше?)
  • Папка проекта
  • Папка проекта 2
  • Ссылки (содержит совместно используемые сборки для решения).

Затем мы просто проверяем все содержание папки решения в нашем репозитории. Мы используем один репозиторий для каждого решения. Я не уверен - ли это оптимальный способ организовать решение, но это работает на нас.

Кроме того, мы переходим на высшем уровне, не на проект.

Иначе:

StackOverflowIsAwesome
  /trunk
    /database
    /datafiles
    /documents
    /build
    /installer
    /lib 
        /External_DAL (external that points to shared library)
    /utilities
    /vendor
    /src
      /StackOverFlowIsAwesome
        /StackOverFlowIsAwesome.csprj
        /bin
        /...
      /StackOverFlowIsAwesomeTests
        /StackOverFlowIsAwesomeTests.csprj
        /bin
        /...
  /branches
  /tags

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

При контакте с несколькими проектами, который составляет Решение для Visual Studio, которое трудно решить, как структурировать вещи правильно.

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

Способность работать на длительные периоды за пределами основной соединительной линии также важна. Необходимо будет рассмотреть это также.

Можно найти, что программное обеспечение имеет много компонентов, это естественно группируется. Вы могли сделать что-то вроде этого

/tag

/core_library
   /branch
   /main

/business_logic
  /branch
  /main

/report_library
  /branch
  /main

/my_ui
  /branch
  /main

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

Можно посмотреть на это предыдущее сообщение или этот проект. Проект создает древовидную структуру разработки.NET (требует.NET 3.5).

Для больших проектов мы обычно используем этот формат здесь:

/Project
    /trunk
       /lib/              # Binary imports here (not in svn)

       /src               # Solution file here
          /Libraries      # Library assemblies here
             /StackOverflowIsAwesome.Common

          /Products       # Delivered products here
             /StackOverflowIsAwesome.Site

          /Projects       # internal assemblies here
             /StackOverflowIsAwesome.Tests
    /branches
        /1.x
    /tags
        /StackOverflowIsAwesome-1.0

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

Независимые проекты под находятся под их собственным корнем Проекта/, но в том же репозитории.

Я делаю это этот путь:

1. Создайте проект в VS
2. Импортируйте все в папке проекта к repos/projectname/trunk
3. Добавьте repos/branches и repos/tags папки

Это дает мне структуру репозитория как:

projectname
    / trunk
        /bin
        /obj
        /Properties
        projectname.sln
    /tags
    /branches

И я могу просто оставить все файлы в их местах по умолчанию в файловой системе.