Hi,
Using the P4 Python API (very similar to command line), I’m trying to figure out if a given file/folder destination is mapped in the users workspace. I’d like to find out without:
Any hints?
By “Mapped” I don’t mean “synced”, but that the file/folder falls within the users workspace
To be sure, you’re going to have to get a list of all workspaces, prune those to the current user/computer, grab the workspace root(s), see which root the file might be under, and then use “p4 fstat” to check.
Alternatively, you can just do a “p4 fstat” on the file name, but this assumes that once again you know the workspace and specify it with -c, or it is the default workspace.
try using p4 where
Yeah, where will work just like fstat, but you still need to know what the workspace name is, or have it set as the default workspace.
I’m just assuming the default workspace (for now at least). If I exclude a specific folder form my workspace, is seems “where” will return paths, that are under that folder regardless. Fstat however does not, but errors with something like “Not in client view view”. Whoot 
Thanks Guys!
Hmm… Not really reliable for files. Anyhow, I’m really just interested in if a “Folder” is theoretically mapped. “Fstat” either returns “No such files” (Doh it’s a folder) or "File(s) not in client view. Doh, I suck at perforce
Something like this then:
def is_in_workspace(path):
"""Return true if file or folder is in a destination that is included in the current workspace"""
with _local_connect():
# Use "where" to get a file like path, regardless of input path type
path = get_file_path(path)
# Strip any file name and extension
if os.path.splitext(path)[1]:
path = os.path.split(path)[0]
try:
p4.run("fstat", path)
except P4Exception:
for e in p4.errors:
print e
for message in p4.messages:
if "file(s) not in client view." in str(message):
return False
return True
Kind of annoying that some commands feedback to message, others to error.
Thanks again
“folders” don’t exist in Perforce as such. You can’t add a folder, you have to add files, and therefore all operations have to be on files. To this point, you will find a lot of files labeled deleteme.txt in our depot if you were to go looking. We use them to stub out folders for future use, or for use by applications (temp directories and such).
Technically speaking folders only exist in perforce if they contain files – the server keeps them as a flat list of paths, and the ‘folders’ exist’ only as indices into the total list of paths.
The closest thing to a listing of directories is p4 dirs. p4 dirs -C will only return directories mapped on the current client
@btibble He he, I know.
It’s just that actual files, do not give reliable output with the “fstat” command. Depends on if they are synced and so on. So while, this is technically incorrect, it get’s the job done
When running the FBX exporter, i can now check it the export dir is included in the workspace. If not refuse to export and throw and explicit error (Actually for a technical reason, I need to know this before exporting any files, that’s why I can’t rely on something like “add” failing with relevant error message).
@ Theodox
Thanks, I’ll give dirs a try.
Cheers
I know you don’t want to parse the workspace but it seems that using ‘p4 client -o [name]’ to grab the ‘Root:’ path and then exclude any excluded ‘View:’ entries would tell you all the folders (existing or potential) that would be valid export locations, and would be trivial to implement.
[QUOTE=Phil;19111]I know you don’t want to parse the workspace but it seems that using ‘p4 client -o [name]’ to grab the ‘Root:’ path and then exclude any excluded ‘View:’ entries would tell you all the folders (existing or potential) that would be valid export locations, and would be trivial to implement.[/QUOTE]
It is much more complex than that because you can subtract locations using the minus sign -//depot/blahdeeblah/…tga, and you can overlay two directories on top of each other on the client. Overlayed directories can even contain files with the same names, and Perforce has deterministic behavior for which file you get. (I believe it is the last file listed in the workspace/clientspec) BTW, working with directories that are overlayed from two or more locations makes adding new files challenging…
Unless you mimic Perforce’s behavior in this regard (difficult), or never do this, then I wouldn’t try it.
Yes - I mentioned excluding the excluded view entries (–//depot/etc), I didn’t see parsing that as an issue.
For the sake of clarity I’ll explain my line of thinking a bit more, so there will be more to tear apart 
From the question and comments I thought Sune was trying to do something rather simple:
[ul]
Determine if an existing file was in Perforce (for exporting an FBX and overwriting one that already exists)
Determine if a potential file that doesn’t exist yet (but is being exported) would be within Perforce clientspec (for exporting a new FBX that is valid to be added to Perforce)
[/ul]
Along with that, Sune mentioned assuming the default workspace and says:
“[…] Actually for a technical reason, I need to know this before exporting any files, that’s why I can’t rely on something like “add” failing with relevant error message).”
As such, I assumed that Sune simply wants to know if the export file path would be valid for adding to Perforce, but was unable to use the ‘add’ command prior to exporting as the export needs to be prevented.
So I frame the question this way:
I need to know if running ‘p4 add’ on a given file (which may not exist yet) will fail or succeed, but I need to know it without actually running ‘p4 add’
For my simple solution, any file path (or potential file path) which is under the root, and not being excluded, would therefore be a valid location (regardless of how the directories are overlaid - it doesn’t need to be a specific location, just a valid location). All that seems to matter is:
[ul]
Is the potential file path under the client root.
Is the potential file path not explicitly being excluded.
[/ul]
As an alternate solution that felt more hacky but is probably just as bad/good:
[ul]Prior to export, create a dummy file with the potential export name, and attempt to add it. If it adds, let the export go through and overwrite it. If it fails, throw the specific error and refuse the export.[/ul]
That was my line of thinking, for better or worse
Phil
The fstat method seems to work, so I’m sticking to my guns for now. Will try your method Phil, when time allows. Thanks all again
[QUOTE=Phil;19122]As an alternate solution that felt more hacky but is probably just as bad/good:
[ul]Prior to export, create a dummy file with the potential export name, and attempt to add it. If it adds, let the export go through and overwrite it. If it fails, throw the specific error and refuse the export.[/ul][/QUOTE]
This. The older I get, them more I realize that the simplest brute force method is sometimes the best.