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

Question

Этот пост похож на этот ранее заданный вопрос. Я действительно хочу настроить свой SVN-репозиторий в формате TTB, но при создании проекта в Visual Studio 2008 (ASP.NET/VB.NET) созданная структура имеет тенденцию быть несовместимой при рассмотрении файла решения, файлов проекта, папок для проектов, нескольких проектов в решениях и т. д. Есть ли у кого-нибудь сценарий или процедура, чтобы взять недавно созданный проект ASP.NET и переместить его в TTB форматировать максимально безболезненно?

---

Позвольте мне быть более конкретным. Предположим, у меня есть проект, который я создаю, который называется StackOverflowIsAwesome. Я могу поместить это в мою локальную структуру папок (скажем, это c: \ working). Когда я его создаю, VS создает c: \ working \ StackOverflowIsAwesome и целую кучу подпапок (bin, app_data и т. Д.). Но я хочу, чтобы структура моего хранилища выглядела как ...

StackOverflowIsAwesome
    /trunk
        /bin
        /app_data
    /tags
    /branches

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

Answer 1

Другой способ:

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.

Answer 2

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

Структура файла:

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

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

Кроме того, мы разветвляемся на самом высоком уровне, а не на проект.

Answer 3

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

/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.

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

Answer 4

Я делаю это так:

1. Создать проект в VS
2. Импортировать все из папки проекта в репозиторий / имя проекта / транк
3. Добавление папок репо / веток и репо / меток

Это дает мне структуру хранилища, такую ​​как:

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

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

Answer 5

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

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

Также важно иметь возможность работать в течение длительных периодов времени вне основного ствола. Вам нужно будет это учитывать.

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

/tag

/core_library
   /branch
   /main

/business_logic
  /branch
  /main

/report_library
  /branch
  /main

/my_ui
  /branch
  /main

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

Answer 6

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

Answer 7

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