Введение

Я бы не согласился с утверждением, что интеграция Perforce в Visual Studio «ужасна». Скорее, я бы определил это как «нестандартный опыт менее чем оптимален» :-). В следующих разделах обсуждается мое понимание интеграции и рекомендации по настройке проекта / решения.

Если вас не интересуют подробности того, как работает интеграция с системой управления версиями, вы можете перейти к концу этого ответа, где я резюмирую ответы на вопрос Weeble.

Заявление об ограничении ответственности: следующие разделы представляют собой просто предположения, основанные на моем эмпирическом опыте, однако я использовал эту технику на протяжении многих лет во многих проектах (каждый проект имеет несколько экспериментальных / основных / обслуживающих / выпускающих ветвей, иногда даже несколько файлов решений без проблем). Недостатком является то, что вам нужно вручную обновлять файлы проекта, но 2-х минутные вложения окупаются в течение всего жизненного цикла проекта, ИМХО :-).

Решение против проекта

Visual Studio использует информацию привязки системы управления версиями как из файла решения, так и из каждого файла проекта во время начальной загрузки решения. Эта информация о привязке затем сохраняется в файле name.suo (при условии, что мы используем name.sln в качестве решения). Обратите внимание, что файлы suo отмечены флажком скрытые, поэтому они не будут видны в проводнике (если вы не переопределите параметр «Скрытые файлы и папки»).

Самый простой способ повторно привязать к поставщику системы контроля версий, если что-то пойдет не так, - это удалить соответствующий файл suo и повторно открыть решение. После создания файла suo изменения в элементах ‹Scc *› не действуют.

Если во время первоначального открытия решения есть несоответствие между информацией привязки, хранящейся в файле решения, и информацией, хранящейся в файле проекта, Visual Studio попытается исправить это (иногда даже будет предложено выбрать, будет ли информация в решении или информацию в проекте следует использовать как «мастер» для устранения несоответствия):

Почему Visual Studio нарушает принцип DRY (Don't Repeat Yourself)? Я понятия не имею. Я предполагаю, что это имеет исторические причины и тесно связано с потребностями того кошмара, который называется Visual Source Safe :-).

Как настроить "правильно"?

Добавляя в Perforce новые или существующие решения / проекты, я всегда начинаю с создания пустого решения (см. Раздел «Управление исходным кодом пустого решения»). Затем я добавляю проекты к этому пустому решению один за другим. Шаги немного различаются в зависимости от того, существует ли уже добавляемый проект (см. Разделы «Управление исходным кодом существующих (несвязанных) проектов» и «Управление исходным кодом существующих (связанных) проектов») или мне нужно создать новый (см. Раздел «Источниковый контроль новых проектов»).

Источник-контроль пустого решения

Чтобы добавить новое пустое решение в систему управления версиями, сделайте следующее:

1. Запустите Visual Studio, «Создать» -> «Проект ...» -> «Другие типы проектов» -> «Пустое решение»; введите название и местоположение решения, нажмите кнопку «ОК»
2. «Файл» -> «Система управления версиями» -> «Добавить решение в систему управления версиями ...»
3. В диалоговом окне подключения введите соответствующий порт сервера P4, клиента и пользователя (обратите внимание, что вид выбранного клиента должен включать местоположение, которое вы выбрали на шаге 1)
4. «View» -> «Pending Checkins» -> «Check In» -> в диалоговом окне отправки вместо нажатия кнопки «Submit» используйте «Cancel».
   Причина: действие «Вернуть» создаст новый файл «name.vssscc», а затем добавит «name.sln» и «name.vssscc» в список изменений Perforce по умолчанию; отменив диалоговое окно отправки, мы сохраним отложенную операцию «добавить» и сможем редактировать файлы перед отправкой в ​​P4.
5. Закройте Visual Studio

6. Откройте файл name.sln в своем любимом редакторе (в блокноте, если вы действительно в отчаянии :-)) и добавьте две новые строки (SccProjectName0 и SccProvider0) - пустое файл решения теперь должен иметь раздел управления версиями, как показано ниже:

   GlobalSection(SourceCodeControl) = preSolution
       SccNumberOfProjects = 1
       SccLocalPath0 = .
       SccProjectName0 = Tutorial
       SccProvider0 = MSSCCI:Perforce\u0020SCM
   EndGlobalSection
   

   Значения следует выбирать следующим образом:

   • SccProjectName0: an arbitrary string that will be displayed in "Change Source Control" dialog as "Server Binding". This name is used to determine what projects/solution files can share the same source control connection. I recommend not using space for this name as escaping rules for spaces are different in solution and project files.
   • SccProvider0: жестко заданное значение «MSSCCI: Perforce \ u0020SCM».
7. Отправьте два ожидающих файла с помощью клиента Perforce по вашему выбору (p4.exe, P4Win, P4V)

Теперь вы можете протестировать привязки:

1. Убедитесь, что Visual Studio закрыта
2. Удалите ** все * файлы, кроме name.sln (особенно name.suo)
3. Откройте Visual Studio и используйте его, чтобы открыть name.sln
4. Должно появиться диалоговое окно подключения, используйте соответствующий порт / клиент / пользователя и нажмите OK.
5. В обозревателе решений теперь должен отображаться узел решения со значком наложения замка:
6. Теперь вы можете проверить состояние системы управления версиями решения, используя «Файл» -> «Управление исходным кодом» -> «Изменить элемент управления исходным кодом ...»: Примечание. В столбце« Привязка сервера »отображается значение, которое мы выбрали для« SccProjectName0 ».

Исходный контроль новых проектов

Если вы создаете совершенно новый проект и хотите немедленно начать его отслеживание в хранилище Perforce, выполните следующие действия:

1. Откройте решение с исходным кодом в Visual Studio
2. «Файл» -> «Добавить» -> «Новый проект ...» - выберите тип проекта, который вы добавляете, имя и местоположение (местоположение должно быть подкаталогом каталога, в котором хранится файл решения).
3. «Файл» -> «Сохранить все» (это зафиксирует все изменения в памяти в файле решения и вновь созданном файле проекта на диске)

4. Вручную отредактируйте файл проекта, который вы только что создали, используя любой редактор по вашему выбору (давай, СНОВА, блокнот? ;-)). Добавьте следующие элементы свойств в PropertyGroup (любую группу свойств):

   <PropertyGroup>
       ...
       <SccProjectName>Tutorial</SccProjectName>
       <SccLocalPath>..\..</SccLocalPath>
       <SccProvider>MSSCCI:Perforce SCM</SccProvider>
       ...
   </PropertyGroup>
   

   Значения следует выбирать следующим образом:

   • SccProjectName - this is the value that is displayed in "Change Source Control" dialog as "Server Binding"; should be the same as the value you used for SccProjectName0 in blank solution; if not the same, solution and this project won't be able to share the same source control provider connection
   • SccLocalPath - относительный путь к справочному каталогу (отображается в диалоговом окне «Изменить источник управления» как «Локальная привязка»); поскольку я рекомендую использовать каталог решения в качестве справочного каталога, это фактически относительный путь от каталога, содержащего файл проекта, до каталога, содержащего файл решения (мой пример хранит проекты в "(solutionDir) /Source/ProjectName/projectName.csproj", таким образом относительный путь - «два уровня вверх»)
   • SccProvider - жестко заданное значение «MSSCCI: Perforce SCM»; это используется, чтобы определить, какой поставщик SCCAPI является значениями привязки Scc *, действительными для

5. Вернитесь в Visual Studio; он должен автоматически определять, что файл проекта был обновлен извне, и предлагать перезагрузить его (в противном случае выгрузить и перезагрузить проект вручную)

6. «Просмотр» -> «Ожидающие проверки»
7. «Вернуть» -> Я рекомендую щелкнуть правой кнопкой мыши файл (solutionName) .vssscc и выбрать «Вернуть, если не изменилось» (даже если Visual Studio открывает его для редактирования, он остается без изменений); предоставьте описание и отправьте изменение

Чтобы убедиться, что новый добавленный проект привязан правильно, вы можете выполнить следующие действия:

1. Убедитесь, что Visual Studio закрыта
2. Удалите файл (solutionName) .suo, а также MSSCCPRJ.SCC (в каталоге решения)
3. Откройте Visual Studio и используйте его, чтобы открыть (solutionName) .sln
4. Должно появиться диалоговое окно подключения, используйте соответствующий порт / клиент / пользователя и нажмите OK.
5. В обозревателе решений теперь должен отображаться узел проекта со значком наложения замка:

6. Теперь вы можете проверить состояние системы управления версиями решения, используя «Файл» -> «Управление исходным кодом» -> «Изменить систему управления версиями ...»:

   В отношении этого снимка экрана состояния следует отметить, что, когда я выбрал строку решения, все оставшиеся строки также были «выбраны» (синяя подсветка). Это связано с тем, что все эти записи имеют одинаковую «привязку сервера» + «локальную привязку» и, таким образом, используют одно и то же соединение с поставщиком управления источником (P4).

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

Исходный контроль существующих (несвязанных) проектов

Если у вас есть существующие проекты, которые еще не использовались в каком-либо другом решении Perforce, выполните следующие действия, чтобы добавить их в Perforce (т. Е. Импортировать проекты, которые ранее не контролировались исходным кодом (загрузки из Интернета и т. Д.) Или использовали другой элемент управления исходным кодом. провайдера (Visual Source Safe и т. д.).

1. Скопируйте проект в соответствующее место
2. Clean-up existing source control bindings (if any):
   • Remove existing project-file bindings, i.e. all properties starting with "Scc"
   • Удалите файл (имя_проекта) .vspscc в том же каталоге, что и файл проекта (если есть)
3. Откройте решение с исходным кодом в Visual Studio
4. «Файл» -> «Добавить» -> «Существующий проект ...» - перейдите к проекту (копия, созданная на шаге 1).
5. «Файл» -> «Сохранить все» (при этом все изменения в памяти будут зафиксированы в файле решения)
6. Выполните шаги 4-7 из раздела «Управление исходным кодом новых проектов» (т.е. теперь вы добавите элементы свойства «Scc *» в PropertyGroup).

Этапы проверки точно такие же, как и в разделе «Исходный контроль новых проектов».

Исходный контроль существующих (связанных) проектов

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

1. Интегрируйте проект в желаемое место
2. Откройте решение с исходным кодом в Visual Studio
3. «Файл» -> «Добавить» -> «Существующий проект ...» - перейдите к проекту, созданному на шаге 1, с помощью интеграции.
4. «Просмотр» -> «Ожидающие проверки» -> «Регистрация» - добавьте описание и отправьте

Резюме

• Информация о привязке системы управления версиями хранится как в решении, так и в проектах, должна быть синхронизирована (в противном случае Visual Studio попытается исправить любые несоответствия)
• Я всегда рассматриваю файлы проекта как основной источник информации о привязке, а файлы решений - как одноразовые файлы, которые можно легко воссоздать, сначала контролируя источник пустого решения, а затем добавляя желаемые проекты.
• Файл решения всегда должен иметь допустимые значения SccProvider0 и SccProjectName0 (их нужно добавлять вручную с новыми версиями плагинов P4SCC).
• Файлы проекта всегда должны иметь допустимые значения SccProjectName (предпочтительно такие же, как SccProjectName0), SccLocalPath и SccProvider (также должны редактировать вручную, так как значения по умолчанию для P4SCC никуда не годятся)

Я также включаю ответы на ваши первоначальные вопросы:

Что происходит, когда вы выполняете «Изменить систему управления версиями» и связываете проекты? Как Visual Studio решает, что поместить в файлы проекта и решения?

Это обновляет элементы «Scc *» в файле проекта, который вы повторно связываете; файл решения затем также обновляется, чтобы он синхронизировался с привязками файла проекта

Что происходит, когда вы выполняете «Открыть из системы контроля версий»?

Позволяет выбрать решение, которое вы хотите открыть. После этого все проекты, включенные в решение, автоматически синхронизируются с головой. Я считаю, что эта функция не очень полезна в мире Perforce, где вам все равно нужно создать клиента, и есть вероятность, что вы синхронизируете этот клиент с P4V / P4Win / P4 вместо того, чтобы полагаться на Visual Studio. Это было отчасти полезно в мире Visual Source Safe, где не было концепции представлений, и вы определяли, где репозиторий будет находиться во время проверки.

Что это за папка «подключения», к которой относятся SccLocalPath и SccProjectFilePathRelativizedFromConnection? Как его выбирает Visual Studio / Perforce?

Это бухгалтерия Visual Studio. Он определяется на основе привязок в каждом файле проекта (я предполагаю, что теоретически, если файл проекта по какой-то причине теряет информацию привязки, он может быть восстановлен из информации о решении ...)

Есть ли какой-либо рекомендуемый способ заставить привязки системы управления версиями продолжать работать даже при создании новой ветки решения?

Я надеюсь, что приведенные выше разделы дадут вам некоторое представление о способе, который мне очень подходит :-).

Сообщение Милана хорошо изучено и написано, но его объем без тени сомнения демонстрирует, что модель P4SCC не работает. Хранить информацию о привязке системы управления версиями в файлах проекта и решения просто нелепо. Столь же нелепо принуждать (через sccprojectname), чтобы проект был частью только одного решения.

Кроме того, P4SCC требует огромных затрат на производительность в большом решении, поскольку он извлекает информацию из системы управления версиями для каждого файла при запуске и поддерживает это состояние в памяти на протяжении всего сеанса разработки. Он создает лишний мусор в виде файлов .vsscc и vssscc без информации для поддержки некоторых функций SCC, которые (AFAICT) Perforce не использует.

Идеальная интеграция Perforce выглядит так:

• Если я создаю новое решение, проект или элемент проекта, запустите p4 add.
• Если я изменю файл, запустите p4 edit.
• Некоторая интеграция панели инструментов / контекстного меню для истории ревизий, графика ревизий, таймлапса / обвинения и «показать в графическом интерфейсе P4».
• (Приятно иметь) Если я переименую файл, который существует в хранилище, запустите «p4 интегрировать» и «p4 удалить». Если я переименую файл, открытый для добавления, запустите p4 revert и p4 add.
• Это все

Мы полностью отошли от P4SCC и его причудливых требований и обременений. Вместо этого мы используем NiftyPerforce. Есть некоторые ошибки, но мы считаем, что работа над ними доставляет гораздо меньше разочарований, чем работа над дефектами конструкции в модели Perforce ‹-> VSSCC.

Просто чтобы поддерживать эту актуальность - плагин P4VS был переписан примерно в 2012 году.

Теперь вы можете выполнять все повседневные операции с Perforce естественным образом, например проверять код и просматривать историю файлов, прямо из среды IDE.

Если вы опытный пользователь, которому нужно немного больше, P4VS вас не разочарует. P4VS полностью совместим с Perforce Streams, а Stream Graph доступен из IDE вместе с Time-Lapse View и Revision Graph. Если вы отвечаете за управление филиалом, вы также можете выполнить слияние из P4VS.

А если вы работаете удаленно или хотите сделать небольшое частное ветвление, P4Sandbox можно настроить через P4VS.

• Страница P4VS на perforce.com
• Веб-семинар о том, как его использовать

Использование Perforce с Visual Studio можно упростить с помощью переменной среды P4CONFIG.

Обычно вы заходите в Visual Studio, Инструменты -> Параметры -> Управление исходным кодом -> Настройки подключаемого модуля, кнопка «Дополнительно». Это вызовет диалоговое окно конфигурации Perforce, относящееся к интеграции SCC. Перейдите на вкладку «Подключение» и установите переключатель «Привязать рабочее пространство, соответствующее настройкам среды Perforce». Это укажет на необходимость предпочесть использование переменной среды P4CONFIG для определения среды, в которой вы находитесь. Этот же диалог существует в P4V в меню Edit -> Preferences, но влияет только на поведение p4v.

Как настроить переменную среды P4CONFIG, в какой-то степени зависит от вас. Мне нравится, когда они везде называются одинаково, поэтому я установил общесистемную переменную среды P4CONFIG для поиска файла с именем p4config.cfg. Этот файл представляет собой просто файл в стиле ini, в котором вы можете назначить другие переменные, такие как P4USER, P4CLIENT, P4HOST и т. Д. Perforce будет искать этот файл в текущем каталоге и во всех родительских каталогах, пока не встретит его. По сути, вы помещаете этот файл в самый корневой каталог вашего жесткого диска, где отображается ваша клиентская спецификация, и оставляете его в покое.

Такой подход значительно снижает количество «корректности», которое требуется конфигурации SCC в Visual Studio для работы. (Привязки SAK работают нормально и т. Д.)

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

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

Все отдельные проекты должны нормально работать с привязками SAK по умолчанию при условии, что вы используете подход P4CONFIG. Исправление этого должно позволить Perforce идеально работать с чистой синхронизацией, а также исключить генерацию мусора MSSCCPRJ.SCC в каждом из каталогов проекта.

Поддержка переименования файла или его перемещения в новый каталог папки ужасна и болезненна при использовании интеграции плагина Visual Studio P4. Не существует встроенной функции, которая предупреждает P4 о переименовании файла или о том, что он был перемещен.

Проблема в том, что для переименования файла требуется не просто обновить связанный файл проекта VS, но и Perforce необходимо проинформировать об изменении, если вы хотите поддерживать надлежащую историю изменений.

В настоящее время я не вижу возможности сделать и то, и другое за одну операцию при использовании интеграции VS. Вместо этого вам необходимо:

1. переименовать / переместить файл из клиента Perforce
2. удалить старую ссылку на имя файла в файле проекта в VS
3. добавить ссылку на новое имя файла в файл проекта в VS
4. отправьте свои изменения

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

Проблема тем больше, чем больше файлов требует переименования или перемещения. Это вовсе не гладкий процесс.

Поэкспериментировав с очень информативным ответом Милана Гардиана, я думаю, что могу предложить более простое решение, чтобы он работал хорошо.

Как упоминал Уибл, значения SAK работают нормально, когда все остальное настроено правильно, и часто они являются значениями по умолчанию (но я думаю, это зависит от типа проекта). Если они не отображаются в вашем проекте, просто вставьте эту группу свойств.

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

Добавьте эти две строки в * .sln в SourceCodeControl GlobalSection. Пока файлы проекта имеют значения SAK, они должны наследовать имена от решения.

SccProjectName0 = Perforce\u0020Project
SccProvider0 = MSSCCI:Perforce\u0020SCM

Не нужно возвращать файлы * .vssscc, * .vspscc или * .SCC (хотя они будут созданы при открытии решения).

Очень плохо. Я знаю, что это не ответ на ваши вопросы, которые вы искали (в будущем, возможно, вы сможете сузить фокус?), Но интеграция системы управления версиями с Visual Studio просто отстой. Причина в том, что все они должны использовать ужасный интерфейс Microsoft SCC. Это жалко! Они помещают информацию об управлении версиями в файлы проекта! Почему они это сделали?

Просто откажитесь от интеграции Visual Studio и используйте клиент Perforce. Это не так уж и много лишней работы. Вы не можете выделить 30 секунд в день, чтобы переключиться на клиент Perforce и оттуда возвращать / выгружать файлы?

Могу ответить на последний.

Чтобы привязки системы управления версиями работали даже при создании новой ветки, следуйте строгой иерархической структуре:

/Solution
  /library1
  /library2
  /product1
  /product2
  /subsolution
    /sublibrary1
    /subproduct1

Каждый файл должен находиться ровно в одном .vcproj. У вас может быть несколько .vcproj в одном каталоге, но если они совместно используют файлы, общие файлы должны находиться в их собственном .vcproj.

Если вы упорствуете в этом, весь материал Scc будет относительным путем, поэтому новая ветка будет работать (потому что она изменяет только самый верхний каталог).

Это не проблема Perforce, это проблема Visual Studio. Нелепое требование, чтобы исходные файлы были изменены, чтобы Visual Studio могла понять, что используется инструмент SCM, - идиотизм.

Простой ответ - «прекратите использовать интеграцию системы управления версиями Visual Studio». Это просто отстой. Даже с TFS это просто отстой.

Если вы хотите иметь возможность оформлять заказ из Visual Studio, просто создайте настраиваемый инструмент. Все, что вам нужно, - это простой вызов p4 edit с соответствующей переменной VS. Хотите восстановить файл? Та же идея ... вызовите p4 revert с соответствующей переменной. Сделанный.

Используйте p4v для управления вашими потребностями в системе контроля версий (отправка, история, различия и т. Д.). Visual Studio отлично работает в качестве редактора исходного кода. Отстой как интерфейс SCM.