VisualSVN и библиотеки классов не в корне рабочей копии - PullRequest
Новая
       25

VisualSVN и библиотеки классов не в корне рабочей копии

6 голосов
/ 02 октября 2008

Мы делаем переход с SourceGear Vault на TortoiseSVN с интеграцией VisualSVN для Visual Studio - это очень нравится. Однако есть несколько библиотек классов, на которые мы ссылаемся в нескольких различных приложениях, которые не являются частью корня рабочей копии ни в одном из приложений. Как лучше всего справиться с этим, чтобы мы могли продолжать использовать интеграцию с Visual Studio, но при этом сохранять различные библиотеки классов, расположенные вне корня каждого проекта / приложения? SourceGear не имеет проблем с этим.

Можно добавить библиотеки классов отдельно, просто используя TortoiseSVN в проводнике, но нет возможности фиксировать изменения чего-либо за пределами рабочей копии из Visual Studio; Также отсутствуют «светофоры» VisualSVN, указывающие их состояние за пределами библиотек классов рабочей копии.

Кстати, мы также идем по пути «один репозиторий со многими проектами», в отличие от нескольких репозиториев, тем более что именно так мы работали годами до этого момента.

UPDATE:

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

См. http://www.visualsvn.com/support/topic/00007/ и http://svnbook.red -bean.com / ru / 1.2 / svn.advanced.externals.html

Однако это лучший способ справиться с этой проблемой? Есть хорошая нить , которая проходит через вещи, но не решает их полностью.

Следовательно, использовать SVN: внешние или нет? Использовать несколько репозиториев или нет? Опять же, в течение многих лет мы ссылались на код в разделяемых библиотеках классов среди множества решений / приложений, и это работает для нас. Теперь, как лучше всего заставить это работать с VisualSVN?

1 Ответ

4 голосов
/ 02 октября 2008

Нашли лучшие ответы здесь :

Ссылочные проекты

Иногда бывает полезно создать рабочую копию, которая состоит из нескольких различных проверок. Например, вы можете захотеть, чтобы разные подкаталоги приходили из разных мест в хранилище, или, возможно, из разных хранилищ. Если вы хотите, чтобы у каждого пользователя был одинаковый макет, вы можете определить свойства svn: externals.

И здесь :

Включить общий подпроект

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

...