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 local 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 graph named 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:

• Additional local depots 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 Helix server 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 tangent is unacceptable.

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 P4 Command Reference.