[p4] Mapping files in Depot to actual Perforce Storage

[Jeff Grills]

As you thought, sometimes revisions may be missing if they are integrated
and unchanged during the integrate process.  1.1.gz might not be the only
revision missing - others can be missing as well.  Certainly the perforce
server needs to be able to figure out where on disk a specific revision
lives, so the data you need has to be somewhere.  This is the type of thing
you're probably best bringing up with perforce support, since they know the
internal workings better than us.  You might try asking them for the DB
schema, though you may still need to reverse engineer some of it.

j

-----Original Message-----
From: perforce-user-bounces at perforce.com
[mailto:perforce-user-bounces at perforce.com] On Behalf Of Weintraub, David
Sent: Thursday, October 12, 2006 2:29 PM
To: perforce-user at perforce.com
Subject: [p4] Mapping files in Depot to actual Perforce Storage


I have decided to implement a script like Richard Baum's trigger which
removes obsolete binary versions of a file. I have a few minor
questions:
 
1). I notice that the binary files names are usually 1.X.gz where "X" is the
revision number of the file. Why do they start with "1."? Could a file be
"2.X.gz"?
 
2). Are all binaries "compressed, so I will expect revision #5 of a file to
be "1.5.gz" and never "1.5"? Or, do I need to look at the file type and
somehow determine whether or not it is compressed.
 
3). I notice that "1.1.gz" is missing in some files. Is this due to the
"lazy copy"  from a branch?
 
4). I want the ability to verify that a particular version of a file
contains no labels. Is the best way to do a "p4 labels <fileName>#<version>"
and see if any labels are listed?