Согласование автономной работы в Perforce не работает для меня

В версии 2009.1 Perforce Visual Client для 32-разрядной Windows опция «Согласовать автономную работу» делает странные вещи. В среднем поле, где должно отображаться «Локальные файлы не в хранилище», я ничего не получаю. Что я действительно вижу, так это то, что в первый раз, когда я согласовываю папку, это выглядит так, как будто по ошибке заполняется поле «локальными файлами, не хранящимися в хранилище», потому что список быстро мигает у меня на глазах. Затем внезапно список быстро исчезает, и у меня остается пустой список. Кто-нибудь знает, как я могу заставить эту функцию показывать мне файлы, которые я еще не добавил? Похоже, что функции «Измененные файлы» и «Складывать файлы, отсутствующие в рабочей области» работают нормально.

Кроме того, в качестве примечания: «Согласование работы в автономном режиме», похоже, нормально работало в бета-версии 2009 года.


offline-mode perforce
person SideFX    schedule 24.08.2009    source источник
comment
Вы сообщили об этом непосредственно в Perforce? Их поддержка обычно очень хорошая.   -  person ChrisF    schedule 25.08.2009
comment
Я просто немного поигрался с этим, и что-то определенно не так. Я бы обсудил это с техподдержкой Perforce.   -  person raven    schedule 26.08.2009
comment
Спасибо за ответ. Я свяжусь с ними, когда у меня будет возможность.   -  person SideFX    schedule 26.08.2009
comment
4 года спустя: согласование автономной работы ВСЕ ЕЩЕ часто сбои и крайне странное, ненадежное поведение в OS X.   -  person pete    schedule 28.02.2014

Ответы (3)


arrow_upward
5
arrow_downward

У меня была точно такая же проблема.

Решение для меня было неясным, но тривиальным.

Я просто изменил корневой каталог моей клиентской рабочей области с «C: \ depot» на «c: \ depot».

Да, все, что я сделал, это изменил букву диска с верхнего на нижний. И, да, я подтвердил, что изменение буквы диска обратно на верхний регистр снова ломает ее, и что изменение буквы диска обратно на нижний регистр снова исправляет это. Так что это не просто совпадение.

Это почти наверняка ошибка функции согласования Perforce.

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

person Adam    schedule 17.10.2009
comment
Это определенно сработало. Спасибо, что разместили свое решение. - person SideFX; 11.01.2010
comment
У меня была та же проблема, и я несколько раз читал ответ Адама, но не заметил своей ошибки. У меня была папка на пути к моему Linux-ящику, в которой был CSi в депо и CSI в рабочем пространстве. Все заработало, кроме согласования автономной работы. После исправления опечатки мне также нужно перейти на вкладку «Рабочая область», поскольку согласование автономной работы не (всегда!) Доступно на вкладке «Депо». Спасибо, Адам, за то, что направил меня в правильном направлении! - person Ant; 02.02.2011
comment
Какие-нибудь другие решения? Я трижды проверил регистр букв в моем корневом пути. Это то же самое, но все же чертовы изменения в автономном режиме Reconcile не показывают файлы, которые удалены из файловой системы и, следовательно, из рабочей области. - person Raj Pawan Gumdal; 26.10.2012
comment
Моя проблема заключалась в том, что он каким-то образом переключил то рабочее пространство, которое я использовал (они выглядят идентично по файловой структуре), поэтому я просто переключился на нужное. Глупая ошибка. - person Hanna; 12.06.2013

arrow_upward
1
arrow_downward

Это, конечно, иногда случается. Мне кажется, что проблема может возникнуть, если я каким-то образом изменю вид рабочего пространства и / или обновлю P4V до новой версии. Итак, решение, которое сработало для меня в прошлом, заключалось в том, чтобы выбросить проблемное рабочее пространство и создать новое (иногда приходилось выбирать другое имя).

Возможно, удаление файлов .p4qt и .p4scc из домашнего каталога пользователя тоже может помочь.

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

person Philip P.    schedule 15.10.2009
comment
Имея такую ​​же проблему. Создал новое рабочее пространство, как было предложено, и действительно работает нормально. Я также попытался удалить .p4qt в домашнем каталоге пользователя, но он все еще не работал, .p4scc тоже не было - person Stephen Lautier; 30.01.2014
comment
У меня здесь в Windows есть репо, в котором нет ограничений по именам файлов и длиннее обычных путей, и согласование не выполняется неоднократно, не уверен, связано ли это, но согласование работает с репозиториями с короткими именами файлов. Я пробовал трюки c: C:, а также -C0 и -C1 для репозиториев без учета регистра. Использование более новой версии инструментов, в которой по умолчанию включен filesys.windows.lfn = 1, но все еще согласовываются разрывы. - person teknopaul; 21.11.2018

arrow_upward
1
arrow_downward

Я обнаружил проблемы с длинными именами файлов в p4 согласовании

из базовой директории

p4 примириться. / ...

никогда не вернулся.

но если я пройду дальше по дереву

Компоненты компакт-диска p4 согласовываются. / ...

работал.

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

person teknopaul    schedule 21.11.2018