Ответ 1

Введение

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

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

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

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

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

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

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

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

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

При добавлении новых или существующих решений/проектов в Perforce, я всегда начинаю с создания пустого решения (см. раздел "Управление исходным кодом пустого решения" ). Затем я добавляю проекты в это пустое решение один за другим. Шаги немного отличаются в зависимости от того, добавлен ли уже добавленный проект (см. Разделы "Существующие (несвязанные) проекты с контролем источника (Source-control existing)" и "Существующие (связанные) источники), или мне нужно создать новый (см. Раздел" Управление новыми источниками").

Исходный контроль пустого решения

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

• Запустите Visual Studio, "Создать" → "Проект..." → "Другие типы проектов" → "Пустое решение"; введите имя и местоположение решения, нажмите кнопку "ОК"
• "Файл" → "Управление источником" → "Добавить решение для управления источником..."
• В диалоговом окне подключения введите соответствующий порт сервера P4, клиент и пользователь (обратите внимание, что представление выбранного клиента должно содержать местоположение, выбранное вами на шаге 1)
• "Просмотр" → "Ожидание проверки" → "Заезд" → в диалоговом окне отправки вместо нажатия кнопки "Отправить", используйте "Отмена".
  Причина. Действие "Check In" создаст новый файл "name.vssscc", а затем добавит "name.sln" и "name.vssscc" в список изменений Perforce по умолчанию; отменив диалог отправки, мы продолжим операцию "добавить", и вы сможете редактировать файлы перед отправкой на P4
• Закрыть Visual Studio

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

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

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

  • SccProjectName0: произвольная строка, которая будет отображаться в диалоговом окне "Изменить источник управления" как "привязка сервера". Это имя используется для определения того, какие проекты/файлы решений могут использовать одно и то же соединение с источником. Я рекомендую не использовать пространство для этого имени, поскольку правила экранирования для пробелов различаются в файлах решений и проектов.
  • SccProvider0: жестко закодированное значение "MSSCCI: Perforce\u0020SCM".
• Отправьте два незавершенных файла, используя клиент Perforce по вашему выбору (p4.exe, P4Win, P4V)

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

• Убедитесь, что Visual Studio закрыта.
• Удалить ** все * файлы, кроме имени .sln(особенно name.suo)
• Откройте Visual Studio и используйте его для открытия name.sln
• Должен появиться диалог подключения, используйте соответствующий порт/клиент/пользователь и нажмите OK
• В обозревателе решений теперь должно отображаться решение node с надписью навесного замка:
• Теперь вы можете проверить статус управления версией решения, используя "Файл" → "Управление источником" → "Изменить контроль источника...": Примечание. В столбце "Связывание с сервером" отображается значение, которое мы выбрали для "SccProjectName0".

Источники, контролирующие новые проекты

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

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

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

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

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

  • SccProjectName - это значение, которое отображается в диалоговом окне "Изменить источник управления" как "привязка сервера"; должен быть таким же, как значение, которое вы использовали для SccProjectName0 в пустом решении; если это не то же самое, решение и этот проект не смогут использовать одно и то же соединение поставщика источника.
  • SccLocalPath - относительный путь к справочному каталогу (отображается в диалоговом окне "Change Source Control" как "Local binding" ); потому что я рекомендую использовать каталог решений в качестве справочного каталога, это по сути относительный путь из каталога, содержащего файл проекта, в каталог, содержащий файл решения (в моем примере хранятся проекты в "(solutionDir)/Source/ProjectName/projectName.csproj", таким образом относительный путь "два уровня вверх" )
  • SccProvider - жестко закодированное значение "MSSCCI: Perforce SCM"; это используется для определения того, какой поставщик SCCAPI является значениями привязки Scc *, действительными для

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

• "Просмотр" → "Ожидающие проверки"
• "Check In" → Я рекомендую щелкнуть правой кнопкой мыши файл (solutionName).vssscc и выбрать "Revert if unchanged" (даже если Visual Studio открывает его для редактирования, он остается неизменным); предоставить описание и отправить изменение

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

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

• Теперь вы можете проверить статус управления версией решения, используя "Файл" → "Управление источником" → "Изменить управление источником...":

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

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

Существующие (несвязанные) проекты с контролем источника

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

• Скопируйте проект в соответствующее место
• Очистка существующих привязок управления источником (если есть):
  • Удалить существующие привязки файлов проектов, т.е. все свойства, начинающиеся с "Scc"
  • Удалить файл (projectName).vspscc в том же каталоге, что и файл проекта (если есть)
• Откройте исходное решение в Visual Studio
• "Файл" → "Добавить" → "Существующий проект..." - перейдите к проекту (копия, созданная на шаге 1)
• "Файл" → "Сохранить все" (это приведет к изменению всех изменений в памяти в файле решения)
• Следуйте шагам 4-7 из "Исходные элементы управления новыми проектами" (т.е. теперь вы добавите элементы свойств "Scc *" в PropertyGroup)

Шаги проверки точно такие же, как в разделе "Управление новыми версиями проектов".

Существующие (связанные) проекты с контролем источника

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

• Интеграция проекта в нужное место
• Откройте исходное решение в Visual Studio
• "Файл" → "Добавить" → "Существующий проект..." - перейти к проекту, созданному на шаге 1, с помощью интеграции
• "View" → "Pending Checkins" → "Check In" - добавить описание и отправить

Резюме

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

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

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

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

Что происходит, когда вы делаете "Open from source control"?

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

Что это за папка "connection", к которой относятся SccLocalPath и SccProjectFilePathRelativizedFromConnection? Как Visual Studio/Perforce выбирает его?

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

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

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

Ответ 2

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

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

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

• Если я создаю новое решение, проект или элемент проекта, запустите 'p4 add'.
• Если я сменил файл, запустите 'p4 edit'.
• Некоторая интеграция с панелью инструментов/контекстного меню для истории изменений, графика пересмотра, timelapse/wame и "show in P4 gui".
• (приятно иметь) Если я переименую файл, который существует в депо, запустите 'p4 integrate' и 'p4 delete'. Если я переименую файл, открытый для добавления, запустите 'p4 revert' и 'p4 add'.
• Что все

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

Ответ 3

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

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

Если вы являетесь сильным пользователем, который ищет немного больше, P4VS не разочарует. P4VS полностью совместим с потоками Perforce, а Stream Stream доступный из среды IDE, а также просмотр по времени и просмотр График. Если вы отвечаете за управление веткими, вы можете объединить от P4VS.

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

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

Ответ 4

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

В основном вы переходите в Visual Studio, Tools → Options → Source Control → Параметры подключаемого модуля, кнопка Advanced. Это вызовет диалог конфигурации Perforce, специфичный для интеграции SCC. Перейдите на вкладку "Соединение" и установите переключатель "Bind the workspace, который соответствует вашим настройкам среды Perforce". Это укажет на необходимость использования переменной среды P4CONFIG для определения среды, в которой вы находитесь. Этот же диалог существует в P4V в разделе Edit → Preferences, но влияет только на поведение p4v.

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

Этот подход значительно уменьшает количество "правильности", которое требуется конфигурации SCC в визуальной студии, чтобы функционировать. (Привязки SAK работают нормально и т.д.)

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

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

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

Ответ 5

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

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

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

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

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

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

Ответ 6

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

Как упоминалось Weeble, значения 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 файлы должны быть проверены (хотя они будут сгенерированы при открытии решения).

Ответ 7

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

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

Ответ 8

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

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

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

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

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

Ответ 9

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

Простым ответом является "прекратить использование интеграции с исходным кодом Visual Studio". Это просто отстой. Даже с TFS это просто отстой.

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

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