Working with depots
All versioned files that users work with are stored in a shared repository called a depot. Files are checked out of the depot for modification and checked back into the depot to archive changes and to share changes with other users.
By default, a depot named
Depot of type
is created in the server when the server starts up. This kind of depot is also referred to as a classic depot. In addition, Helix server creates a default depot of type
repo. A graph depot serves as a container for Git repos. To be able to store Git data in a graph depot, you need to license Helix4Git. For more information on graph depots, see the Helix4Git Administrator Guide.
You can also create additional depots of various types:
localdepots allow you to organize users' work in relevant categories. You might, for example, want to separate HR source docs from development source docs.
- Stream depots are dedicated to the organization and management of streams.
- A spec depot is used to track changes to user-edited forms such as workspace specifications, jobs, branch mappings, and so on.
- Archive depots are used to offline storage of infrequently needed content.
- Unload depots are used to offline storage of infrequently needed metadata.
- Remote depots are used to facilitate the sharing of code.
- A tangent depot is generated by
and used internally to store conflicting changes during fetch
operations. The only action the administrator might want to take with
respect to the tangent depot is to rename it if its default name of
Server extensions are versioned in a special extensions depot. For more information, see Helix Core Extensions Developer Guide.
This chapter includes general information about working with depots of
different types. The
p4 depot command, used to create
any type of depot, is described in
Helix Core Command-Line (P4) Reference.