Привязки Visual Studio - связанные и несвязанные sc в разных решениях - PullRequest
Новая
       23

Привязки Visual Studio - связанные и несвязанные sc в разных решениях

3 голосов
/ 30 марта 2012

У меня есть команда разработчиков, которая разделяет менталитет использования привязок управления исходным кодом Visual Studio. Половина хотела бы интеграции, а половина - нет. Есть ли способ добавить решение, связывающее настройки, чтобы каждая группа могла использовать свое решение в зависимости от своих предпочтений?

Ответы [ 3 ]

3 голосов
/ 06 апреля 2012

Нет безболезненного решения этой проблемы.Причина в том, что Microsoft приняла монументально плохое решение встроить информацию об управлении исходными кодами в .NET-решение и файлы проекта.

Допустим, Дик хочет использовать плагин SCC, а Джейн нет.Дик добавляет проект к управлению версиями через плагин, и такая информация будет записана в файл решения: 

GlobalSection(SourceCodeControl) = preSolution
    SccNumberOfProjects = 2
    SccLocalPath0 = .
    SccProjectUniqueName1 = someApp\\someApp.csproj
    SccLocalPath1 = someApp
EndGlobalSection

, и некоторая фигня, подобная этой, будет добавлена ​​в файлы проекта: 

<SccProjectName>SAK</SccProjectName>
<SccLocalPath>SAK</SccLocalPath>
<SccAuxPath>SAK</SccAuxPath>
<SccProvider>SAK</SccProvider>

Кроме того, некоторые файлы будут разбросаны по дереву папок проекта (файлы MSSCCPRJ.SCC в папках решения и проекта, * .vssscc в папке решения и файлы * .vspscc в папках проекта)..

Дополнительные файлы не являются проблемой, если Дик не проверяет их в системе контроля версий (хотя плагин всегда захочет проверить эти файлы .vssscc и .vspscc).Однако информация об управлении исходным кодом, которая записывается в решение и файлы проекта, всегда будет раздражать Джейн.Всякий раз, когда она открывает решение, она будет раздражена этим сообщением:

enter image description here

, а затем это:

enter image description here

Следуетона выберет опцию «Окончательно удалить привязки управления исходным кодом», информация об исходном контроле будет удалена из файла решения и проекта, и она снова будет счастлива.Однако плагин Дика SCC больше не будет работать, и он, вероятно, свяжет проекты с контролем исходного кода, и начнется бунт в офисе.

Подводя итог, вы можете поделиться проектом .NET между теми, кто используетПлагин SCC и те, кто этого не делает, но одной или нескольким сторонам придется пережить некоторые неприятности, потому что Microsoft решила добавить информацию об управлении исходным кодом в файлы проекта .NET (такое плохое решение, это не было проблемой в Visual Studio6).

0 голосов
/ 18 июля 2013

Вы должны убедиться, что никогда не проверяете созданный файл MSSCCPRJ.SCC плагином.

Я удалил * .scc файлы, но Visual Studio не позволяет мне использовать другие плагины Source Controls, кроме сохраненных в файлах решений и проектов.

0 голосов
/ 05 апреля 2012

Я не совсем уверен, правильно ли я вас понял.Я предполагаю, что половина вашей команды хочет использовать плагин Visual Studio для доступа к Perforce, а другая половина - нет.

Это возможно.Вы должны убедиться, что никогда не проверяет файл MSSCCPRJ.SCC, созданный плагином.Это информация о локальных привязках, которая не будет работать на всех рабочих станциях.

С другой стороны, файлы * .vssscc могут и должны идти в Perforce.

Использование плагина имеет одинПреимущество: плагин знает , какие файлы регистрировать, а какие опускать.Особенно при добавлении новых проектов, распространенной ошибкой является забыть регистрировать вновь созданные файлы при использовании визуального клиента Perforce вместо плагина.

...