Locate a file in a stream depot using only task stream spec

Question

In order to get a p4 print of a arbitrary file, i'm looking for a way to locate the correctly 'resolved' file using only a stream spec, not a client one.

For example,

Main stream have a file

//toto/main/file.txt  

Second stream //toto/test/ is a task stream parented to main stream using the following spec

share ...

When I try to locate and print toto.txt in the stream test using

p4 print //toto/test/file.txt

I receive different output depending on different factors.

• If the file was never submitted in the test stream

  • If I'm in a client (using -c Client_Test or any other way to set the client) in the right stream, the file is located by p4 and printed correctly.

  • If I'm not specifying the client, or not giving p4 any indication regarding which client it should use, I receive the following error

//toto/test/file.txt - no such file(s).

• If the file was submit on the test stream, the file is located and printed correctly.

My goal is to be able to print an arbitrary file without using a workspace, as if I understood correctly, stream spec should be able to locate a file in a streams hierarchy.

I could try to look recursively in the parent stream, if the file is present there, with the command

p4 print //toto/main/file.txt

But that solution wouldn't work in the case where the file 'file.txt' is coming from another stream with the following mapping

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

It seems there is no way to locate this kind of file without specifying a client (workspace) to work with (and unfortunately that is not an acceptable solution in our environnement)

Answer 1

Given that your primary concern is to do this as efficiently as possible (minimal impact on the server and minimal scripting), I would suggest doing the following:

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

The "client -s" command has no appreciable server overhead since it is not manipulating any file content or even any file metadata; it is simply creating the "view" that the stream forms a template for, which in turn provides a context for running other commands by defining which depot files you're working with in the context of that stream. This is what makes the "//Client_Test/file.txt" syntax map to the correct file whether it's in the "shadow table" of the task stream, or the publicly viewable portion of the depot, or an import from another stream, or a remapped path in the parent stream, et cetera.

If for philosophical reasons you are determined not to use a client spec, you could do:

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

This will show you the client view without actually creating a client spec in the database. Using one of the Perforce scripting APIs it's not too difficult to capture the "View" field and then turn it into a Map object -- this is how you'd figure out where imports come from, allowing you to handle the exception you mentioned, with some difficulty.

If you are philosophically prevented from even looking at a hypothetical client view via the "p4 client" command, your next best option is to parse the stream spec itself; there is of course a deterministic system for generating a view from a stream spec, so you could re-implement this system yourself, with a much greater amount of difficulty.

However, if the primary concerns are efficiency and ease, I would recommend using a client spec. If you're still skeptical about the server overhead, run those commands with "-Ztrack" to see how little work they need to do, e.g.:

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

Note that only a single database entry was rewritten for the actual client switch; the bulk of the overhead is the basically negligible amount associated with authentication and output (the single line telling me it succeeded).