Why The Spec Depot File Might Not Match The Specification

I was comparing an old group specification from my Perforce server spec depot against the specification itself, and it does not look the same. Is the spec depot not working properly?

The specification forms are a human readable means of displaying and editing underlying database values that are stored in Perforce meta-data. They should not be confused with the data itself. The spec depot stores the form as an archived file that is immutable -- future updates to Perforce cannot change those forms.

For example, a Perforce administrator creates a group using a 2007.3 Perforce server:

Group:dev_groupMaxResults:unlimitedMaxScanRows:unlimitedTimeout:0Subgroups:Users:brunoabigalroni

Perforce adds this to the spec depot as //spec/group/dev_group.p4s exactly as it appeared in the default editor.

Over time the Perforce server is updated to 2008.2, and the output from p4 group -o dev_group now appears as:

Group:dev_groupMaxResults:unsetMaxScanRows:unsetMaxLockTime:unsetTimeout:unsetSubgroups:Owners:Users:brunoabigal roni

Perforce server version 2008.2 added the MaxLockTime limit, changed the "unlimited" option to "unset", and eliminated the use of "0" to represent a maximum timeout value, replacing it with "unset" as well. Perforce converts the old values that now no longer work, and adds the MaxLockTime as unset as part of a new group specification format. While it does differ in appearance, the specification will have the same original functionality unless otherwise noted in the release notes. In this example, there is no current equivalent to the "0" Timeout value, so it switches to the default timeout value of 12 hours.

Note: This does present an issue if you use a shortcut to reset a specification using p4 print and -i flags. Using the same group example, this command would not work:

p4 print -q //spec/group/dev_group.p4s#3 | p4 group -iError in group specification.Error detected at line 24.Invalid maximum value '0'.While there is no built-in method in Perforce for updating those specifications you can safely change the versioned files themselves. One thing that helps this process is that each specification is stored as an individual compressed file, or file type "ctext". The basic process to "update" a specification, assuming that the spec depot is in the Perforce root directory: Navigate to the comma-d (,d) folder in the spec depot versioned files folder.

For example, for the group "dev_group" you would enter the command: cd $P4ROOT/spec/group/dev_group.p4s,d

Note: The ".p4s" suffix is the default for spec depots, as is the depot name "spec". Check the spec depot specification for the actual depot name, suffix (if used) and location of the versioned specification files.

Inside this directory you will see a list of gzipped (*.gz) files similar to: 1.1.gz1.2.gz1.3.gzThe highest numbered file is the head revision of that specification. In most cases, this is the only file you would need to decompress using the command: gunzip 1.3.gzOr, if you would like to change all the stored group specifications, you could use this command: gunzip -r $P4ROOT/spec/group

At this point, there are several options:

If this is a single file, open the the file and manually change the specification.For multiple files, you can use a text editor to do a bulk find and replace across multiple files. BBEdit on the Mac OS or SlickEdit under Windows have this capability, for example.You can create a script to do the find and replace.Once you have modified the files: Re-compress the files using gzip. For a single file: gzip 1.3For multiple files (using the above example): gzip -r $P4ROOT/spec/groupTo avoid errors when running "p4 verify", use this command to recalculate the digests for those files: p4 verify -v //spec/group/...Note: This is a good idea even if you do not normally verify the specification depot. This prevents any future misunderstanding if a new administrator were to run a broader verification, and see a large number of BAD errors in the specification depot.

While groups are being used in this example, this technique can be used to modify any specification file in the spec depot.

Note: As with any low level changes, test those steps against a duplicate of your Perforce server thoroughly before implementing in your production server. Contact Perforce Support if you have any questions.

View the original article here