Найдите файл в хранилище потоков, используя только спецификацию потока задач

Question

Чтобы получить p4-печать произвольного файла, я ищу способ найти правильно "разрешенный" файл, используя только спецификацию потока, а не клиентскую спецификацию.

Например,

Основной поток имеет файл

//toto/main/file.txt  

Второй поток //toto/test/ - это поток задач, связанный с основным потоком с использованием следующей спецификации

share ...

Когда я пытаюсь найти и распечатать toto.txt в тесте потока с помощью

p4 print //toto/test/file.txt

Я получаю разные результаты в зависимости от разных факторов.

• Если файл никогда не был представлен в тестовом потоке

  • Если я нахожусь в клиенте (используя -c Client_Test или любой другой способ установить клиента) в правильном потоке, файл расположен на p4 и печатается правильно.

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

//toto/test/file.txt - таких файлов нет.

• Если файл был отправлен в тестовом потоке, файл расположен и распечатан правильно.

Моя цель - иметь возможность напечатать произвольный файл без использования рабочей области, как если бы я правильно понял, спецификация потока должна быть в состоянии найти файл в иерархии потоков.

Я мог бы попытаться посмотреть рекурсивно в родительском потоке, если файл там присутствует, с помощью команды

p4 print //toto/main/file.txt

Но это решение не будет работать в случае, если файл 'file.txt' поступает из другого потока со следующим отображением

import file.txt //toto/otherTaskStream/file.txt

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

Answer 1

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

p4 -c Client_Test client -s -S //toto/test
p4 -c Client_Test print //Client_Test/file.txt

Команда "client -s" не имеет заметных издержек на сервере, поскольку она не манипулирует каким-либо содержимым файла или даже метаданными файла; это просто создание "представления", для которого поток формирует шаблон, который, в свою очередь, предоставляет контекст для запуска других команд, определяя, с какими файлами депо вы работаете в контексте этого потока. Это то, что заставляет синтаксис "//Client_Test/file.txt" отображаться в правильный файл, находится ли он в "теневой таблице" потока задач, или в общедоступной части хранилища, или при импорте из другого потока, или переназначенный путь в родительском потоке и так далее.

Если по философским причинам вы решили не использовать спецификацию клиента, вы можете сделать:

p4 -c nonexistentclientspec client -o -S //toto/test

Это покажет вам представление клиента без фактического создания спецификации клиента в базе данных. Используя один из скриптовых API Perforce, не так уж сложно захватить поле "Вид", а затем превратить его в объект "Карта" - так вы узнаете, откуда происходит импорт, что позволит вам обработать исключение, которое вы упомянули, с некоторыми трудностями.

Если вам философски запрещено даже просматривать гипотетическое представление клиента с помощью команды "p4 client", ваш следующий лучший вариант - проанализировать саму спецификацию потока; конечно, существует детерминированная система для генерации представления из спецификации потока, так что вы можете заново внедрить эту систему самостоятельно, с гораздо большей сложностью.

Тем не менее, если основными проблемами являются эффективность и простота, я бы порекомендовал использовать спецификацию клиента. Если вы все еще скептически относитесь к накладным расходам сервера, запустите эти команды с "-Ztrack", чтобы увидеть, как мало работы им нужно, например:

C:\p4\test>p4 -Ztrack -c Client_Test client -s -S //stream/task
Client Client_Test switched.
--- lapse .015s
--- rpc msgs/size in+out 0+1/0mb+0mb himarks 2000/2000 snd/rcv .000s/.000s
--- db.user
---   pages in+out+cached 3+0+2
---   locks read/write 1/0 rows get+pos+scan put+del 1+0+0 0+0
--- db.group
---   pages in+out+cached 3+0+2
---   locks read/write 1/0 rows get+pos+scan put+del 0+1+1 0+0
--- db.stream
---   pages in+out+cached 7+0+2
---   locks read/write 5/0 rows get+pos+scan put+del 1+11+11 0+0
--- db.domain
---   pages in+out+cached 14+8+2
---   locks read/write 8/2 rows get+pos+scan put+del 10+0+0 2+0
--- db.template
---   pages in+out+cached 8+0+2
---   locks read/write 6/0 rows get+pos+scan put+del 0+6+12 0+0
--- db.view
---   pages in+out+cached 6+4+2
---   locks read/write 2/1 rows get+pos+scan put+del 0+2+4 1+1
--- db.have
---   pages in+out+cached 3+0+2
---   locks read/write 0/0 rows get+pos+scan put+del 0+1+1 0+0
---   peek count 1 wait+held total/max 0ms+0ms/0ms+0ms
--- db.working
---   pages in+out+cached 5+0+2
---   locks read/write 2/0 rows get+pos+scan put+del 0+3+3 0+0
---   peek count 1 wait+held total/max 0ms+0ms/0ms+0ms
--- db.trigger
---   pages in+out+cached 3+0+2
---   locks read/write 1/0 rows get+pos+scan put+del 0+1+1 0+0
--- db.bodtext
---   pages in+out+cached 3+0+2
---   locks read/write 1/0 rows get+pos+scan put+del 2+0+0 0+0
--- db.protect
---   pages in+out+cached 3+0+2
---   locks read/write 1/0 rows get+pos+scan put+del 0+1+3 0+0
--- db.monitor
---   pages in+out+cached 6+6+2
---   locks read/write 0/2 rows get+pos+scan put+del 0+0+0 2+0

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