Documentation

OBJECTSPEC

Get information on how to build object specifications with the Unity Version Control CLI.

Read time 2 minutes

Last updated 21 days ago

Description

Describes how to write object specs.

Usage


cm objectspec

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

Help

Several UVCS 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.