Repository Organization

How to organize the Perforce repository in part determined by how it will be partitioned into IPs.  Each IP points to a particular (arbitrary) location in the repository, so the components of the IP must exist under that path.

What is an IP?

An IP is in essence:

a group of files(directories) that should be released independently as a unit

It is usually clear from a designer's perspective how to partition a particular design.  Each component typically has a number of sub-components that are designed and tested either independently or semi-independently. 

Experience has shown that the maximum value can be obtained from Perforce IPLM when each of these at least semi-independent sub components is managed as its own IP.  Some customers initially are concerned about having 'too many' IPs in the system and are reluctant to divide the design into as many independent IPs as may be warranted.  There is of course room for debate about where exactly to draw the line, but there are some considerations to keep in mind:

  • A designer in a multi-designer environment shouldn't be restricted in making releases of IPs they are responsible for.  Ideally they will be able to make releases as needed, any sections of the design under another designer's control should be a separate IP. This is true whether the other designer's section of the design is a sub-block or a block that references the first designer's IP.
  • The act of making a release immutably preserves the state of the design at that time, allowing the easy consumption of the design at a known state.  This enables continuous delivery and facilitates top level transparency, which should be encouraged.
  • If design activity on a portion of the design is static compared to another portion of the design they should probably reside in separate IPs
  • Perforce IPLM tracks as many IPs as required, and the relationships between them automatically, so there is little overhead in adding more IPs
  • Design data is one component of an IP, but it may make sense to track the documentation and other support files along with the design data
  • A too big IP puts an undue burden on workspace creation, each IP can be put in the cache and kept in refer mode which effectively allows it to be loaded instantly into a new workspace.  Dividing up the design into more IPs allows users to load only what they need into their local workspace, which is time and disk space efficient.
  • A too big IP decreases transparency, there may be logical blocks inside the IP whose states should be publicized
  • If a section of the design is a candidate for re-use it should be its own IP

Types of IP

IP are typically of one of two types:

  • Project Specific IPs are used in a single project (or iteration of a project). 
  • Global IPs can be used across a range of projects, a standard cell Library for instance.

How to Organize the IPs in the Repository

The exact path used to contain IPs in the repository will vary from customer to customer, but for project specific IPs should contain the project name, the Library name, the IP name, and the Line name:

//(p4_depot_name)/project_name/library_name/IP_name/Line_Name/<IP data>

Global IPs should also be organized with the applicable identifying information needed to make the nature of the IP clear:

//(p4_depot_name)/design_type/additional_functionality/process_node/library_name/IP_Name/Line_Name/<IP data>

Creating a New Perforce Depot

Perforce Depots are created with the 'p4 depot' command

> p4 depot newdepot

This brings up the depot template:

# A Perforce Depot Specification.
#
#  Depot:       The name of the depot.
#  Owner:       The user who created this depot.
#  Date:        The date this specification was last modified.
#  Description: A short description of the depot (optional).
#  Type:        Whether the depot is 'local', 'remote',
#               'stream', 'spec', 'archive', 'tangent',
#               'unload', 'extension' or 'graph'.
#               Default is 'local'.
#  Address:     Connection address (remote depots only).
#  Suffix:      Suffix for all saved specs (spec depot only).
#  StreamDepth: Depth for streams in this depot (stream depots only).
#  Map:         Path translation information (must have ... in it).
#  SpecMap:     For spec depot, which specs should be recorded (optional).
#
# Use 'p4 help depot' to see more about depot forms.

Depot:	newdepot

Owner:	mdx

Date:	2018/11/05 17:15:45

Description:
	Created by mdx.

Type:	local

Map:	newdepot/...

which can be saved by saving and exiting the template. The existing depots in the system can be shown with the 'p4 depots' command:

> p4 depots
Depot depot 2018/08/28 local depot/... 'Default depot'
Depot mdx_test 2018/08/28 local mdx_test/... 'Created by root. '
Depot newdepot 2018/11/05 local newdepot/... 'Created by mdx. '