Как интеграция управления версиями Visual Studio работает с Perforce? - PullRequest
71 голосов
/ 04 ноября 2008

Мы используем Perforce и Visual Studio. Всякий раз, когда мы создаем ветку, некоторые проекты не будут связаны с управлением исходным кодом, если мы не будем использовать «Открыть из управления исходным кодом», но другие проекты работают независимо. Из моих расследований я знаю некоторые вещи:

В наших файлах .csproj есть следующие настройки:

Иногда все они установлены на "SAK", иногда нет. Кажется, что с большей вероятностью все сработает, если они скажут "SAK".

В нашем файле .sln есть настройки для многих проектов:

  • SccLocalPath #
  • SccProjectFilePathRelativizedFromConnection #
  • SccProjectUniqueName #

(# - это число, которое идентифицирует каждый проект.) SccLocalPath - это путь относительно файла решения. Часто это ".", Иногда это папка, в которой находится проект, а иногда это ".." или ".. \ ..", и, кажется, плохо указывать на папку выше папка решения. Релятивизированный - это путь из этой папки к файлу проекта. Он будет полностью отсутствовать, если SccLocalPath указывает на папку проекта. Если в SccLocalPath есть «..», этот путь может включать имена папок, которые не совпадают между ветвями, что, как мне кажется, вызывает проблемы.

Итак, чтобы окончательно добраться до специфики, которую я хотел бы знать:

  • Что происходит, когда вы выполняете «Изменить управление исходным кодом» и связываете проекты? Как Visual Studio решает, что поместить в файлы проекта и решения?
  • Что происходит, когда вы делаете «Открыть из контроля источника»?
  • Что это за папка «подключения», на которую ссылаются SccLocalPath и SccProjectFilePathRelativizedFromConnection? Как Visual Studio / Perforce выбирает это?
  • Есть ли какой-нибудь рекомендуемый способ, чтобы привязки управления исходным кодом продолжали работать даже при создании новой ветви решения?

Добавлено июнь 2012: Я больше не использую Perforce, поэтому я не могу ручаться за это, но посмотрите на ответ KCD ниже. Очевидно, новый плагин P4 VS находится в стадии разработки. Надеюсь, это все прояснит!

Ответы [ 9 ]

102 голосов
/ 09 февраля 2009

Введение

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

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

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

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

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

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

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

alt text

Почему Visual Studio нарушает принцип СУХОЙ (не повторяй себя)? Я понятия не имею. Я предполагаю, что это имеет исторические причины и тесно связано с потребностями этого кошмара, называемого Visual Source Safe: -).

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

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

Источник-контроль пустого раствора

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

  1. Запустите Visual Studio, «Создать» -> «Проект ...» -> «Другие типы проектов» -> «Пустое решение»; введите название и местоположение решения, кнопка «ОК»
  2. «Файл» -> «Контроль источника» -> «Добавить решение в контроль источника ...»
  3. В диалоговом окне подключения введите соответствующий порт сервера P4, клиента и пользователя (обратите внимание, что представление выбранного клиента должно включать местоположение, выбранное вами на шаге 1)
  4. «Просмотр» -> «Ожидание регистрации» -> «Регистрация» -> в диалоговом окне отправки вместо нажатия кнопки «Отправить» используйте «Отмена».
    Причина : действие «Регистрация» создаст новый файл «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 : произвольная строка, которая будет отображаться в диалоговом окне «Изменить управление исходным кодом» как «Привязка к серверу». Это имя используется для определения того, какие файлы проектов / решений могут совместно использовать одно и то же соединение контроля версий. Я рекомендую не использовать пробел для этого имени, так как экранирующие правила для пробелов различаются в файлах решений и проектов.
    • 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. В обозревателе решений теперь должен отображаться узел решения со значком наложения замка: Source-controlled blank solution
  6. Теперь вы можете проверить состояние контроля источника решения, используя «Файл» -> «Контроль источника» -> «Изменить контроль источника ...»: Source control status of blank solution Примечание. В столбце «Привязка к серверу» отображается значение, выбранное для «SccProjectName0».

Управление исходными кодами новых проектов

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

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

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

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

    • SccProjectName - это значение, которое отображается в диалоговом окне «Изменить управление исходным кодом» как «Привязка к серверу»; должно совпадать со значением, которое вы использовали для SccProjectName0 в пустом решении; если не одно и то же, решение и этот проект не смогут использовать одно и то же соединение с поставщиком контроля версий
    • 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. Удалить (имя решения) .suo файл, а также MSSCCPRJ.SCC (в каталоге решения)
  3. Откройте Visual Studio и используйте его для открытия (solutionName) .sln
  4. Должно появиться диалоговое окно подключения, используйте соответствующий порт / клиент / пользователя и нажмите OK
  5. В обозревателе решений теперь должен отображаться узел проекта со значком наложения замка: Source-controlled projects
  6. Теперь вы можете проверить состояние контроля источника решения, используя «Файл» -> «Контроль источника» -> «Изменить контроль источника ...»: Status of source-controlled projects

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

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

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

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

  1. Скопируйте проект в соответствующее место
  2. Очистить существующие привязки контроля источника (если есть):
    • Удалить существующие привязки файла проекта, то есть все свойства, начинающиеся с "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. Он определяется на основе привязок в каждом файле проекта (теоретически, если файл проекта по какой-либо причине теряет информацию привязки, его можно восстановить из информации решения ...)

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

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

22 голосов
/ 20 марта 2010

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

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

Идеальная интеграция с Perforce выглядит следующим образом:

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

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

9 голосов
/ 22 июня 2012

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

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

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

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

5 голосов
/ 06 июля 2011

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

В основном вы заходите в Visual Studio, Инструменты -> Параметры -> Контроль источника -> Настройки плагина, Кнопка Дополнительно. Это вызовет диалоговое окно конфигурации Perforce, специфичное для интеграции SCC. Перейдите на вкладку «Подключение» и установите переключатель «Привязать рабочую область, которая соответствует вашим настройкам среды Perforce». Это скажет Perforce, что вы предпочитаете использовать переменную окружения P4CONFIG для определения среды, в которой вы находитесь. Этот же диалог существует в P4V в меню «Правка» -> «Настройки», но влияет только на поведение 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 в каждом из каталогов проекта.

4 голосов
/ 27 ноября 2008

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

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

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

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

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

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

3 голосов
/ 03 марта 2011

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

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

2 голосов
/ 07 ноября 2008

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

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

1 голос
/ 06 ноября 2008

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

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

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

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

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

0 голосов
/ 11 июня 2013

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

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

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

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

...