Мы переходим с SourceGear Vault на TortoiseSVN с VisualSVN для интеграции с Visual Studio - нам это очень нравится. Однако существует несколько библиотек классов, на которые мы ссылаемся в нескольких различных приложениях, которые не являются частью корня рабочей копии ни в одном из приложений. Как лучше всего справиться с этим, чтобы мы могли продолжать использовать интеграцию Visual Studio, но при этом сохранять различные библиотеки классов, расположенные вне корня каждого проекта / приложения? У SourceGear нет проблем с этим.
Можно добавлять библиотеки классов отдельно, просто используя TortoiseSVN в проводнике, но нет возможности фиксировать изменения чего-либо за пределами рабочей копии из Visual Studio; также нет «светофоров» VisualSVN, указывающих на их статус за пределами библиотек классов рабочих копий.
Кстати, мы также идем по пути «один репозиторий со многими проектами», а не с несколькими репозиториями, тем более что именно так мы работали до этого момента годами.
ОБНОВИТЬ:
Я перечитал некоторые вещи, на которые я смотрел раньше, и обнаружил, что svn: externals не просто относятся к использованию кода в разных репозиториях, но также могут использоваться для использования нескольких рабочих копий в VisualSVN.
См. http://www.visualsvn.com/support/topic/00007/ и http://svnbook.red-bean.com/en/1.2/svn.advanced.externals.html
Однако это лучший способ справиться с этой проблемой? Есть хорошая тема, который проходит через вещи, но не решает их полностью.
Следовательно, использовать svn: externals или нет? Использовать несколько репозиториев или нет? Опять же, в течение многих лет мы ссылались на код в общих библиотеках классов из нескольких решений / приложений, и это работает для нас. Теперь, как лучше всего заставить это работать с VisualSVN?





Нашел лучшие ответы здесь:
Упомянутые проекты
Иногда бывает полезно создать рабочую копию, состоящую из нескольких различных проверок. Например, вы можете захотеть, чтобы разные подкаталоги поступали из разных мест в репозитории или, возможно, из разных репозиториев вообще. Если вы хотите, чтобы у всех пользователей был одинаковый макет, вы можете определить свойства svn: externals.
И здесь:
Включите общий подпроект
Иногда вы захотите включить в свою рабочую копию другой проект, возможно, какой-нибудь библиотечный код. Вы не хотите делать дубликат этого кода в своем репозитории, потому что тогда вы потеряете связь с исходным (и поддерживаемым) кодом. Или, может быть, у вас есть несколько проектов с общим кодом ядра. Есть как минимум 3 способа справиться с этим.
Я понимаю, что с тех пор, как вы задали этот вопрос, прошло более десяти лет, но я рад сообщить вам, что был достигнут прогресс в реализации поддержки нескольких рабочих копий в подключаемом модуле VisualSVN.
VisualSVN 7.1 и 6.5 поддержка нескольких рабочих копий в одном решении. Новая функциональность доступна пользователям Visual Studio 2019 и 2017 г..
Загрузите последние сборки VisualSVN из основного файла страница загрузки. Также смотрите статью KB7: Использование нескольких рабочих копий в VisualSVN.
Я должен ответить, по крайней мере, поблагодарить вас за преданность / VisualSVN!