OBJECTSPEC#

Description#

Describes how to write object specs.

Usage#

cm objectspec

(To get all the information about how to build object specs.)

Help#

Several Unity VCS commands expect 'object specs' as input to refer to a given object (typically a branch, changeset, repository, etc).

This documentation describes the different "specs" available and how to build them.

Each spec type begins with a unique tag, for example "rep:" or "cs:". The tag must be specified for commands that take a general object spec, for example "cm setowner object_spec", but can often be omitted for commands that take only a single type of spec, for example, "cm getfile revision_spec".

Repository server spec (repserverspec)#

repserver:name:port

Examples#

cm repo list repserver:skull:8084

cm repo list skull:8084

Side note#

We call it 'repository server spec', instead of just 'server spec' for historical reasons. Long ago, we had separate workspace and repository servers, and the naming survived.

Repository spec (repspec)#

rep:rep_name@[repserverspec]

Examples#

cm showowner rep:codice@localhost:6060

(Here the "rep:" is required because showowner admits not only repos but also other types of objects. So it needs the user to indicate the object type.)

Branch spec (brspec)#

br:[/]br_name[@repspec]

Examples#

cm switch br:/main@rep:plastic@repserver:skull:9095

(In this case "br:", "rep" and "repserver" are not needed, so the command admits a much shorter form: "cm switch main@plastic@skull:9095".)

cm find revisions "where branch='br:/main/task001'"

Remark#

The initial '/' on the branch is not mandatory. We used to specify all our branches as /main, /main/task001, and so on. But now, we prefer the shorter form main, main/task001 which makes commands more compact.

Changeset spec (csetspec)#

cs:cs_number|cs_guid[@repspec]

The number or GUID of the changeset can be specified.

Examples#

cm ls /code --tree=ae1390ed-7ce9-4ec3-a155-e5a61de0dc77@code@skull:7070

Label spec (labelspec)#

lb:lb_name[@repspec]

Examples#

cm switch lb:RELEASE2.0

cm switch lb:RELEASE1.4@myrep@MYSERVER:8084

Revision spec#

There are different types of rev specs#

• rev: item_path[#(brspec|csetspec|labelspec)]
• rev: serverpath:item_path#(brspec|cset_spec|lb_spec)
• rev: revid:rev_id[@rep_spec]
• rev: itemid:item_id#(br_spec|cset_spec|lb_spec)

Examples#

cm diff rev:readme.txt#cs:19 rev:readme.txt#cs:20

cm diff serverpath:/doc/readme.txt#cs:19@myrepo serverpath:/doc/readme.txt#br:/main@myrepo@localhost:8084

cm cat revid:1230@rep:myrep@repserver:myserver:8084

Item spec#

There are different types of item specs#

• item: item_path
• item: itemid:item_id[@rep_spec]

Examples#

cm lock unlock item:audio.wav

cm lock unlock itemid:1234@rep:myrep@repserver:myserver:8084

Attribute spec#

att:att_name[@repspec]

Example#

cm attribute set att:merged@code@doe:8084 cs:25@code@doe:8084 done

Shelve spec#

sh:sh_number[@repspec]

Example#

cm diff sh:2 sh:4

Workspace specs#

wk:name@clientmachine

Rarely used, since they only apply to workspace related commands. Useful to specify the workspace by name and machine instead of path.

Examples#

cm showselector wk:codebase@modok

Side note#

These specs come from the old days of Plastic SCM 2.x where 'workspace servers' existed as a way to store workspace metadata in a centralized way. Were deprecated due to performance issues.