К сожалению, нет гарантии, что все рабочее пространство их клиентов было синхронизировано только с одним списком изменений, когда они были отложены. В крайнем случае они могли синхронизировать каждый файл с другим номером изменения.
Тем не менее, они, вероятно, синхронизированы с одним моментом времени, и вы можете экстраполировать это по номерам ревизий файлов на их полке.
$ p4 files @=1000
//depot/foo/bar.txt#3 - edit change 1000 (text)
//depot/baz/quux.c#5 - edit change 1000 (text)
Номера ревизий после имен файлов указывают ревизию каждого готового файла, который пользователь синхронизировал перед открытием для редактирования.
Затем вы можете запустить p4 files с каждым путем к файлу и ревизией, чтобы получить номера изменений:
$ p4 files //depot/foo/bar.txt#3 //depot/baz/quux.c#5
//depot/foo/bar.txt#3 - edit change 983 (text)
//depot/baz/quux.c#5 - edit change 998 (text)
Выберите наибольший из числа изменений из второй команды и попробуйте синхронизировать ваш клиент с этим.
Предостережения к вышесказанному
Даже если мы предположим, что они синхронизированы с одним моментом времени, вышеприведенное не является надежным. Это только говорит нам, что они синхронизируются с изменением после или включая 998 и до 1000.
Допустим, они синхронизируются, чтобы изменить 999. Их рабочее пространство клиента могло выглядеть так:
$ p4 have
//depot/an/otherfile#7 - /home/user/a/an/otherfile
//depot/foo/bar.txt#3 - /home/user/a/foo/bar.txt
//depot/baz/quux.c#5 - /home/user/a/baz/quux.c
Допустим, что это было изменение 999, которое обновило другой файл до версии 7, и это изменение 999 содержало только другой файл.
Поскольку другой файл никогда не был отложен, а последняя вышедшая на полку ревизия вышла из изменения 998, вы не можете сделать вывод, основываясь на полке, была ли синхронизирована рабочая область клиента для изменения 998 или 999.
Еще большее предостережение заключается в том, что все это развалится, если они синхронизируют разные файлы с разными номерами изменений, но обычно люди этого не делают.