Можете ли вы сохранить информацию привязки управления исходным кодом Visual Studio из файлов .sln и .csproj?

Question

My Visual Studio 2005 хранит информацию о том, какие проекты и решения и с какими репозиториями системы контроля версий содержатся в файлах .sln и .csproj. Можно ли заставить его хранить эту информацию о привязке в каком-то внешнем файле?

Причина, по которой я хочу, чтобы информация хранилась вне файлов решения / проекта, заключается в том, чтобы облегчить эксперименты с плагином AnknSVN. Прямо сейчас у нас есть все наши вещи в VSS 6, но я хочу сохранить экспериментальную копию репозитория SVN, а затем вручную синхронизировать их, используя идеи, описанные здесь:

http://www.dotnet6.com/blogs/jeroen/archive/2008/04/05/using-subversion-in-a-vss-only-shop.aspx

К сожалению, привязки, хранящиеся в файле .sln (например), приводят к этому. Для иллюстрации, скажем, я копирую весь свой VSS-репозиторий в параллельный экземпляр SVN. Теперь я открываю основное решение из SVN в Visual Studio с помощью AnknSvn; в этом процессе AnkhSvn изменит информацию о привязке управления исходным кодом в файле .sln, указав SVN. Далее, скажем, я добавляю новый проект P1 к решению. Это заставит Visual Studio изменить файл .sln во второй раз, отметив существование P1. Скажем, на данный момент я хочу синхронизировать изменения, внесенные в копию SVN, обратно в репозиторий VSS. Если привязка управления исходным кодом не сохранена в файле .sln, это не так уж плохо. Однако теперь в файле .sln есть два разных изменения, и я хочу распространить изменение добавления проекта обратно на VSS, но я не хочу распространять изменение привязки управления исходным кодом обратно на VSS, потому что это сломало бы построить для всех пользователей VSS! Я не думаю, что есть способ распространить одно изменение без другого ручного вмешательства. В отличие от этого, если бы Visual Studio просто сохраняла информацию о привязке вне файла .sln, то я действительно хотел бы распространить все изменения файла .sln обратно на VSS, и это было бы нормально.

Answer 1

VisualSVN не использует плагин экосистемы управления исходным кодом (SCC), поэтому не загрязняет ваше решение или файл проекта. Это коммерческая лицензия, но очень разумная цена <50 долларов. Таким образом, позволяя вам продолжать использовать неприятный VSS (хотя в идеале исключайте каталоги .svn) </p>

Answer 2

АнхСВН 2.0 имеет два режима работы.

• Подключено (рекомендуется). Это хранит информацию о привязке в .sln и необязательно файлах проекта.
• Отключено. Это не сохраняет привязку.

Вы можете подключить и отключить решение и отдельные проекты в File-> Subversion-> Change Source Control.

Преимущества подключения:

• Автоматическое переключение между провайдерами SCC при открытии решения (например, между VSS, TFS и AnkhSVN)
• Совместим со всеми типами проектов, в которых реализована поддержка SCC.
• (2.1+) Автоматическая обработка проектов вне основной рабочей копии. (Например, веб-сайты в c: \ inetpub)

Примечание. Если вы ранее использовали AnkhSVN 1.X в решении, вам следует вручную удалить файлы Ankh.load. Когда AnkhSVN 2.0 видит файл Ankh.load, он автоматически подключает ваше решение.

[Follow up:]
Простой способ использовать AnkhSVN рядом с другой реализацией SCC - просто создать дополнительный файл .sln. AnkhSVN не использует фактические значения в полях SCC отдельного проекта. (Нужно просто вставить их, чтобы включить проект для полного управления SCC)

Answer 3

IIRC и AnkhSVN, и VSS реализуют привязку контроля версий строго с помощью файлов .sln / .csproj (интерфейс плагина контроля версий VS облегчает этот тип хранения). Поэтому короткий ответ - нет.

Однако вы все равно можете использовать Subversion в качестве внешнего решения для управления версиями, которое с точки зрения безопасности и стабильности было бы намного лучше, чем VSS, использующий либо командную строку (книга ). твой друг), или TortoiseSVN .

Answer 4

Коллега написал эту задачу для удаления привязок.

http://www.atalasoft.com/cs/blogs/jake/archive/2008/05/21/2custom-nant-task-for-removing-tfs-bindings.aspx

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