[p4] Spec depots?

G Barthelemy gb.perforce at googlemail.com
Thu Mar 26 09:23:12 PDT 2009

On Thu, Mar 26, 2009 at 2:05 PM, Philip Panyukov
<ppanyukov at googlemail.com> wrote:
> Hello,
> We are thinking of creating a spec depot since we had workspaces and
> other things accidentally deleted in the past and those were very
> difficult (and at times impossible) to restore.
> What is the general view on these?  Does anyone use these?  Is it a
> good idea, bad idea to have a spec depot?  Any gotchas?

The spec depot is very useful, not just to recover client specs or
other artifacts, but for forensic purposes (in conjunction with the
server log).

Set it up and populate it straight away (p4 admin updatespecdepot -a).

It's a read-only depot, so any protection above read is irrelevant.
You may want to prevent access to records that only superusers have
access to normally, for consistency sake. For instance, I tend to
prevent users from being able to see //spec/protect.p4s, etc... since
they don't have access to p4 protect -o in the first place.

Here's a gotcha I've hit once. I don't know if that's still relevant.
The default file type in a spec depot is ctext IIRC. Which means that
for each record, a sub-directory will be created in the corresponding
RCS store. If you have a large amount of a particular type of record -
say over 32767 clients or jobs or branches, etc... and use the ext2 or
ext3 filesystem, then you may hit a limit in the number of directories
that your filesystem can create and your users get this cryptic
message when submitting a fix:

$ p4 submit -c 580939
Change 580939 created with 1 open file(s) fixing 1 job(s).
Warning: couldn't archive to spec depot (spec/job/X12345.p4s)
mkdir: spec/job/X12345.p4s,d: Too many links

So best is to set the file type for some of the specdepot records to
text, by having entries like these in typemap:
        text //spec/job/...
        text //spec/client/...


More information about the perforce-user mailing list