Как работать с подмодулями Git в решениях Visual Studio различной компоновки?

Question

Мы разрабатываем с Visual Studio 2010 (на C #) и недавно перешли с SVN на GIT.Теперь мы пытаемся разделить наш репозиторий (который довольно большой - ~ 30 000 файлов) на множество репозиториев git - по одному для каждого решения.Решения используют некоторые проекты, в основном библиотеки, которые мы разрабатываем собственными силами и которые хотели бы добавить из всех решений.

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

Проблема возникает с внешними ссылками в подмодулях.В новых репозиториях путь к ссылочному проекту может быть "...... libs \ someproject", тогда как в новом макете правильный путь будет ".. \ someproject".

Мы ужеУ меня было несколько войн редактирования, связанных с этим, и они не заинтересованы в большем.

Полуфабрикаты Решения, о которых я мог подумать:

• использовать "ссылочные пути" в ... csproj.user и исключить этот файл из системы контроля версий (необходимо переделывать для каждого разработчика и после каждой очистки репозитория)

• использовать ветки для каждой ситуации и пытаться научить всех, где "настоящие" коммитыдолжен идти и куда должны идти коммиты "изменение среды" (подмодули уже не самая простая концепция ...)

• вставлять двоичные файлы вместо подмодулей (но как насчет разработки измененийсубмодули? как насчет различных версий log4net?)

Кто-нибудь знает о здравом подходе?

Answer 1

Поскольку вы запрашиваете разумное решение, я могу только посоветовать вам заняться настройкой собственной службы NuGet (см. http://www.MyGet.org для вдохновения)

http://nuget.codeplex.com/

Answer 2

ЕСЛИ вы идете по маршруту управления пакетами, рассмотрите OpenWrap.Однако встраивание артефактов управления пакетами в исходный код - плохая идея.Вы можете использовать такие инструменты для обновления того, что на самом деле хранится в подмодулях, но не полагайтесь на них во время сборки.Ожидайте, что двоичные файлы будут там с точки зрения ваших сценариев сборки.

Answer 3

У меня похожая проблема при использовании VS 2013.

Я хочу использовать git-svn вместо SVN напрямую.У SVN есть гигантский набор каталогов.Я не мог создать единственный git-репозиторий, который содержал бы всю нашу папку ствола.Git-всегда выходил с ошибкой, а хранилище было повреждено.Я обошел проблему, выполнив следующие действия:

1. Используя git-svn, я клонировал подмножество нужных мне папок из SVN / trunk, создав один git-репозиторий на папку.1007 * Создан локальный родительский репозиторий git, содержащий все мои клонированные git-svn папки.
2. Каждый git-репозиторий был добавлен в качестве подмодуля в родительский git-репозиторий.1012 * Проблема с Visual Studio заключается в том, что он не распознает несколько проектов за пределами основного проекта, в котором я открыл решение.Это решение находится в папке, которая содержит единственные файлы, распознаваемые Visual Studio как находящиеся под контролем git-source.

   Я попытался настроить параметры git для использования родительского каталога верхнего уровня в качестве расположения git-файла.хранилище, не замечая никакой разницы.

Answer 4

Так что, если я вас правильно понял, проблема в Visual Studio, а не в Git?Если это так, используйте старую древовидную структуру, которая работала с Visual Studio.Сделайте так, чтобы ваши подмодули также имели древовидную структуру.Таким образом, вершиной дерева будет один супер-репо, чьи подмодули (ветви) будут иметь свои собственные подмодули, пока вы не дойдете до листьев вашего дерева.Поначалу было бы сложно настроить, но это должно сработать.

Answer 5

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