Hi Guys,
I’d like to query Perforce (command line) if a file exists in the depot or not - regardless of whether there is a match between the casing in the query and the actual file in the depot:
Query: Do you have file "//myProject/Butcher.FBX"?
If the file is in the deopt, I’d then like to have it’s path returned, with casing that matches what is in the depot:
Yes, I have file: "//MyProject/butcher.FBX"
Any pointers?
Thanks 
The fstat command should do this. Regardless of the case used in the command, both the “depotFile” and “clientFile” return values should have the case used by the actual file.
C:\>p4 fstat //myProject/.../Butcher.FBX
... depotFile //MyProject/butcher.FBX
... clientFile C:\MyProject\butcher.FBX
... isMapped
... headAction edit
... headType binary+l
... headTime 1291215397
... headRev 4
... headChange 801601
... headModTime 1283173604
... haveRev 4
P4 “files” command will also work. Runs faster than fstat, too.
C:\>p4 files //myProject/.../Butcher.FBX
//MyProject/butcher.FBX#4 - edit change 801601 (binary+l)
One thing to note. The above P4 commands will only return what Perforce thinks the case is on that file. If Perforce created that file via a sync, the case on the file will match what says. However, if a user or another tool renamed it so that the case is different, Perforce will still report the original case, since technically neither it nor Windows cares.
If that’s a problem you could use Perforce to locate the file as shown above, then use another means of verifying the case on the actual file. In Python, for instance, you could feed the path Perforce returns into something like this:
>>> import os
>>> filenames = os.listdir( r'C:\myproject' )
>>> [ f for f in filenames if f.lower( ) == 'butcher.fbx' ][ 0 ]
'BuTchER.Fbx'
Hi Adam, thanks for that!
If I understand correctly, Perforce server can be set-up to differentiate between casing or not. In our case casing is turned on… (I’m assuming that’s why neither fstat and files work as you describe when run my end :tear: )
This means that if the depot already contains “//myProject/Butcher.FBX” and I add //MYPROJECT/butcher.fbx, the depot will now contain 2 files - not a good thing!
Any other ideas?
Talk to your perforce administrator?
He he - yeah I did :):
They had no suggestion of how to check for files in the depot in a “case agnostic” way.
As for the server being set-up with case sensivity, that’s a blunder, but unfortunately not something that will go away on this project.
If perforce does not provide a handle for doing this, I guess I’ll roll my own hack.
Thanks
We very recently switched our P4 server to run on Windows instead of Linux. Traditionally ALL of our clients have been Windows, so we’ve ran into the case sensitivity issue a few times.
Biggest issues have been middleware (Hello Havok, I’m looking at you, and Autodesk) deciding to change a folder name to be “lowerCaseStart” to be “LowerCaseStart”. And artists changing case, until we forced all lower case on all art assets. And a few newbie programmers who weren’t used to the company naming mantra properly yet. Which is confusingly enough CamelCase for source code.
Anyway, when migrating the server from Linux to Windows, we seemed to have ended up with almost 8000 collisions (including all the branch history, so it wasn’t that bad) in about 7 years.
Double-checking all the real conflicts (cpp, h, cs, py, etc files) took a few days, for all the rest of the case sensitivity collisions we decided to branch into //depot/collisions as lower case and just nuked everything except the newest revisions (.psd, .max etc).
But, if you EVER switch your Perforce server OS and need to migrate the database over - prepare for a lot of emails sent over with Perforce support and several dry runs, with a bunch of script hacks for rename (aka integrate) of the assets.
After the migration to running the server on a Windows machine, it’s been fairly smooth.
We were aware of the ability to continue running the server on a Linux machine with a case-insensitive file system, but that sounded even more scary than migrating it over to Windows.
I think the rule of thumb is that keep the server on the same OS as most of the clients.
SamiV.
You don’t have to match OS’s on the server and clients. For instance, we run a Linux server with all Windows clients. The crucial bit, though, is if you do have any Windows clients in play, make sure the server is configured to be case-insensitive.
Sune, sounds like that’s late advice for you guys at this point, but hopefully you can get it fixed up next project.
I’ve always worked with case-sensitive Perforce. I like it- it keeps me on my toes! Is there a performance difference? Anyway, conceptually, I prefer the case sensitivity, even if it does cause problems occasionally (and occasionally not so occasionally).
Yes, you can’t check for p4 files case insensitively if the server is case sensitive. Or at least, I never found a way when I spoke to our P4 admin at Bioware. You asked for a perforce command so I’ll spare some idea about how you’d do it on the client side by case-insensitive-HashSet’ing the result of a p4 files (which could be done quite fast, if you want I can write up a sample impl in python or preferably .NET).
One of the problems with running Windows servers seems to be issues with file path length. Of course you might want this limitation, if you ever want to say have an external vendor set-up a proxy server to work on your stuff, since they might not be able to set-up a Linux box.
As for future projects, I’m pretty confident that one of the first server setting that will be made, is case in-sensitivity!
@Rob: I’d love to see any code you have or a mock-up. I have my own idea of how to do it, but I’m not sure it’s very elegant
Thanks again guys
Now is the time to focus on your customers, on your key talent, on communicating clearly and authentically, and, most of all, on creating a positive, adaptive work climate in which people raise their personal level of responsibility, add more to their team’s success, and, at the same time, feel recognized for their contributions.