Configure server to limit storage of archive revisions

Recall that server files have two portions: the file data itself  — known as the archive or archive file — and the file’s metadata  — information describing the file, such as its size and its owner.

Because digital asset archives take up substantial storage space, it would be convenient to control how many revisions of the archive you store locally when you fetch the digital asset files to your personal server. Moreover, because source code doesn’t impose this same storage burden, it would be equally helpful to control the source code archive files separately from the digital assets when fetching quantities of archives.

The ArchiveLimits: field in the personal server’s remote spec allows you to do just this. Using ArchiveLimits:, you specify how many revisions of a file or files archive(s) you want to store locally with a fetch. This is regulated at the level of one or more files, so if you store your digital asset files in separate subdirectories from source code files, you can impose the archive limits on just the digital asset files, leaving source code files unaffected.

ArchiveLimits: does not affect the fetched files' metadata; the fetch stores metadata for the entire history of the files.

If you don’t set ArchiveLimits: the server defaults to storing all archive revisions.

Note

ArchiveLimits: are applied during the p4 fetch operation only. However, since they apply to p4 fetch, they also affect p4 clone, if they are set in the remote spec invoked by p4 clone.

ArchiveLimits: entries

An ArchiveLimits: entry consists of a sequence of one or more lines of the form filespec depth, where:

  • filespec is a file or subdirectory of files
  • depth dictates how many relative revisions of the archive files to store

The depth field can be a non-negative integer, or the special word all, which tells the server to store all revisions of the file or files specified in that line’s filespec. Setting depth to 0 tells the server not to store any archives for files specified in this line’s filespec.

The integer value 0 means that a fetch will not store any archive files, just metadata, for the files specified in the filespec entry on this line.

A positive integer N means that no more than N archives should be stored for each file in this section of your repo. For example, suppose you have a file whose latest revision is 17 and the depth setting for the ArchiveLimits: entry governing this file is 2. This means that when the file is fetched, the server will store the archive for revisions 17 and 16 only.

Recall that since ArchiveLimits: behavior operates at the level of a filespec, you can separate what the server does with digital assets files from what it does with source code simply by:

  1. storing the digital assets files in a distinct folder from the source code files
  2. describing ArchiveLimits: behavior for each of these folders on separate lines

Consider the following sample ArchiveLimits: entry: 

ArchiveLimits:
    //.../*.zip 1
    //.../*.iso 0
    //.../*.rpm 0
    //depot/main/.../*.zip 3
    //depot/rel*/.../*.zip all
    //depot/.../*.mp4 2

This would result in the server behavior summarized in the following table:

File or files Server behavior

//depot/main/my/proj/component/MyClass.java

All revisions of the archive file are stored on the server

//artifacts/Windows/Windows10.iso

No archive is ever stored for this file

//depot/main/my/proj/builds/myProj.zip

The three most recent revisions of the archives are stored on the server

//depot/dev/my/proj/builds/myProj.zip

Only the most recent revision of the archive is stored on the server

//depot/rel1.0/my/proj/builds/myProj.zip

All revisions of archives are stored on the server