Масштабируемое решение - svn-external в каталоге решений , чтобы импортированные проекты отображались параллельно с другими проектами. Причины этого приведены ниже.
Использование отдельного подкаталога для "импортированных" проектов, например externals, через svn-external кажется хорошей идеей, пока у вас нет нетривиальных зависимостей между проектами. Например, предположим, что проект A зависит от проекта в проекте B, а проект B - от проекта C. Если у вас есть решение S с проектом A, вы получите следующую структуру каталогов:
# BAD SOLUTION #
S
+---S.sln
+---A
| \---A.csproj
\---externals
+---B <--- A's dependency
| \---B.csproj
\---externals
\---C <--- B's dependency
\---C.csproj
Используя эту технику, вы можете даже получить несколько копий одного проекта в своем дереве . Это явно не то, что вы хотите.
Более того, если ваши проекты используют зависимости NuGet , они обычно загружаются в каталог packages верхнего уровня. Это означает, что NuGet ссылки проектов в подкаталоге externals будут повреждены .
Кроме того, если вы используете Git в дополнение к SVN, рекомендуемый способ отслеживания изменений состоит в том, чтобы иметь отдельный репозиторий Git для каждого проекта, а затем отдельный репозиторий Git для решения, которое использует * 1027. *git submodule для проектов в пределах. Если подмодуль Git не является непосредственным подкаталогом родительского модуля, то команда подмодуль Git создаст клон, который является непосредственным подкаталогом .
Еще одним преимуществом наличия всех проектов на одном слое является то, что вы можете затем создать «супер-решение», которое содержит проекты из всех ваших решений (отслеживаемых через Git или svn-external), что, в свою очередь, позволяет вам проверьте с помощью одного решения - перестройте, чтобы любое изменение, внесенное вами в один проект, соответствовало всем другим проектам .
# GOOD SOLUTION #
S
+---S.sln
+---A
| \---A.csproj
+---B <--- A's dependency
| \---B.csproj
\---C <--- B's dependency
\---C.csproj