RepositoryDeleteDepot Method
|
Delete a depot from the repository
Namespace:
Perforce.P4
Assembly:
p4api.net (in p4api.net.dll) Version: 2024.1.265.5426
Syntax public void DeleteDepot(
Depot depot,
Options options
)
Public Sub DeleteDepot (
depot As Depot,
options As Options
)
public:
void DeleteDepot(
Depot^ depot,
Options^ options
)
member DeleteDepot :
depot : Depot *
options : Options -> unit
Parameters
- depot
- Type: Perforce.P4Depot
The depot to be deleted - options
- Type: Perforce.P4Options
Only the '-d' flag is valid when deleting an existing depot
Remarks
p4 help depot
depot -- Create or edit a depot specification
p4 depot name
p4 depot -d [-f] name
p4 depot -o name
p4 depot -i
Create a new depot specification or edit an existing depot
specification. The specification form is put into a temporary file
and the editor (configured by the environment variable $P4EDITOR)
is invoked.
The depot specification contains the following fields:
Depot: The name of the depot. This name cannot be the same as
any branch, client, or label name.
Owner: The user who created this depot.
Date: The date that this specification was last modified.
Description: A short description of the depot (optional).
Type: One of the types: 'local', 'stream', 'remote', 'spec',
'archive', or 'unload'.
A 'local' depot (the default) is managed directly by
the server and its files reside in the server's root
directory.
A 'stream' depot is a local depot dedicated to the
storage of files in a stream.
A 'remote' depot refers to files in another Perforce
server.
A 'spec' depot automatically archives all edited forms
(branch, change, client, depot, group, job, jobspec,
protect, triggers, typemap, and user) in special,
read-only files. The files are named:
//depotname/formtype/name[suffix]. Updates to jobs made
by the 'p4 change', 'p4 fix', and 'p4 submit' commands
are also saved, but other automatic updates such as
as access times or opened files (for changes) are not.
A server can contain only one 'spec' depot.
A 'archive' depot defines a storage location to which
obsolete revisions may be relocated.
An 'unload' depot defines a storage location to which
database records may be unloaded and from which they
may be reloaded.
Address: For remote depots, the $P4PORT (connection address)
of the remote server.
Suffix: For spec depots, the optional suffix to be used
for generated paths. The default is '.p4s'.
Map: Path translation information, in the form of a file
pattern with a single ... in it. For local depots,
this path is relative to the server's root directory
or to server.depot.root if it has been configured
(Example: depot/...). For remote depots, this path
refers to the remote server's namespace
(Example: //depot/...).
SpecMap: For spec depots, the optional description of which
specs should be saved, as one or more patterns.
The -d flag deletes the specified depot. If any files reside in the
depot, they must be removed with 'p4 obliterate' before deleting the
depot. If any archive files remain in the depot directory, they may
be referenced by lazy copies in other depots; use 'p4 snap' to break
those linkages. Snap lazy copies prior to obliterating the old depot
files to allow the obliterate command to remove any unreferenced
archives from the depot directory. If the depot directory is not
empty, you must specify the -f flag to delete the depot.
The -o flag writes the depot specification to standard output. The
user's editor is not invoked.
The -i flag reads a depot specification from standard input. The
user's editor is not invoked.
Examples
To delete a streams depot named MobileApp:
Depot d = Repository.GetDepot("MobileApp");
Repository.DeleteDepot(d, null);
See Also