diff options
Diffstat (limited to 'docs/manifest_xml.txt')
-rw-r--r-- | docs/manifest_xml.txt | 158 |
1 files changed, 158 insertions, 0 deletions
diff --git a/docs/manifest_xml.txt b/docs/manifest_xml.txt new file mode 100644 index 00000000..da0e69ff --- /dev/null +++ b/docs/manifest_xml.txt | |||
@@ -0,0 +1,158 @@ | |||
1 | repo Manifest Format | ||
2 | ==================== | ||
3 | |||
4 | A repo manifest describes the structure of a repo client; that is | ||
5 | the directories that are visible and where they should be obtained | ||
6 | from with git. | ||
7 | |||
8 | The basic structure of a manifest is a bare Git repository holding | ||
9 | a single 'default.xml' XML file in the top level directory. | ||
10 | |||
11 | Manifests are inherently version controlled, since they are kept | ||
12 | within a Git repository. Updates to manifests are automatically | ||
13 | obtained by clients during `repo sync`. | ||
14 | |||
15 | |||
16 | XML File Format | ||
17 | --------------- | ||
18 | |||
19 | A manifest XML file (e.g. 'default.xml') roughly conforms to the | ||
20 | following DTD: | ||
21 | |||
22 | <!DOCTYPE manifest [ | ||
23 | <!ELEMENT manifest (remote*, | ||
24 | default?, | ||
25 | remove-project*, | ||
26 | project*)> | ||
27 | |||
28 | <!ELEMENT remote (EMPTY)> | ||
29 | <!ATTLIST remote name ID #REQUIRED> | ||
30 | <!ATTLIST remote fetch CDATA #REQUIRED> | ||
31 | <!ATTLIST remote review CDATA #IMPLIED> | ||
32 | |||
33 | <!ELEMENT default (EMPTY)> | ||
34 | <!ATTLIST default remote IDREF #IMPLIED> | ||
35 | <!ATTLIST default revision CDATA #IMPLIED> | ||
36 | |||
37 | <!ELEMENT project (EMPTY)> | ||
38 | <!ATTLIST project name CDATA #REQUIRED> | ||
39 | <!ATTLIST project path CDATA #IMPLIED> | ||
40 | <!ATTLIST project remote IDREF #IMPLIED> | ||
41 | <!ATTLIST project revision CDATA #IMPLIED> | ||
42 | |||
43 | <!ELEMENT remove-project (EMPTY)> | ||
44 | <!ATTLIST remove-project name CDATA #REQUIRED> | ||
45 | ]> | ||
46 | |||
47 | A description of the elements and their attributes follows. | ||
48 | |||
49 | |||
50 | Element manifest | ||
51 | ---------------- | ||
52 | |||
53 | The root element of the file. | ||
54 | |||
55 | |||
56 | Element remote | ||
57 | -------------- | ||
58 | |||
59 | One or more remote elements may be specified. Each remote element | ||
60 | specifies a Git URL shared by one or more projects and (optionally) | ||
61 | the Gerrit review server those projects upload changes through. | ||
62 | |||
63 | Attribute `name`: A short name unique to this manifest file. The | ||
64 | name specified here is used as the remote name in each project's | ||
65 | .git/config, and is therefore automatically available to commands | ||
66 | like `git fetch`, `git remote`, `git pull` and `git push`. | ||
67 | |||
68 | Attribute `fetch`: The Git URL prefix for all projects which use | ||
69 | this remote. Each project's name is appended to this prefix to | ||
70 | form the actual URL used to clone the project. | ||
71 | |||
72 | Attribute `review`: Hostname of the Gerrit server where reviews | ||
73 | are uploaded to by `repo upload`. This attribute is optional; | ||
74 | if not specified then `repo upload` will not function. | ||
75 | |||
76 | Element default | ||
77 | --------------- | ||
78 | |||
79 | At most one default element may be specified. Its remote and | ||
80 | revision attributes are used when a project element does not | ||
81 | specify its own remote or revision attribute. | ||
82 | |||
83 | Attribute `remote`: Name of a previously defined remote element. | ||
84 | Project elements lacking a remote attribute of their own will use | ||
85 | this remote. | ||
86 | |||
87 | Attribute `revision`: Name of a Git branch (e.g. `master` or | ||
88 | `refs/heads/master`). Project elements lacking their own | ||
89 | revision attribute will use this revision. | ||
90 | |||
91 | |||
92 | Element project | ||
93 | --------------- | ||
94 | |||
95 | One or more project elements may be specified. Each element | ||
96 | describes a single Git repository to be cloned into the repo | ||
97 | client workspace. | ||
98 | |||
99 | Attribute `name`: A unique name for this project. The project's | ||
100 | name is appended onto its remote's fetch URL to generate the actual | ||
101 | URL to configure the Git remote with. The URL gets formed as: | ||
102 | |||
103 | ${remote_fetch}/${project_name}.git | ||
104 | |||
105 | where ${remote_fetch} is the remote's fetch attribute and | ||
106 | ${project_name} is the project's name attribute. The suffix ".git" | ||
107 | is always appended as repo assumes the upstream is a forrest of | ||
108 | bare Git repositories. | ||
109 | |||
110 | The project name must match the name Gerrit knows, if Gerrit is | ||
111 | being used for code reviews. | ||
112 | |||
113 | Attribute `path`: An optional path relative to the top directory | ||
114 | of the repo client where the Git working directory for this project | ||
115 | should be placed. If not supplied the project name is used. | ||
116 | |||
117 | Attribute `remote`: Name of a previously defined remote element. | ||
118 | If not supplied the remote given by the default element is used. | ||
119 | |||
120 | Attribute `revision`: Name of the Git branch the manifest wants | ||
121 | to track for this project. Names can be relative to refs/heads | ||
122 | (e.g. just "master") or absolute (e.g. "refs/heads/master"). | ||
123 | Tags and/or explicit SHA-1s should work in theory, but have not | ||
124 | been extensively tested. If not supplied the revision given by | ||
125 | the default element is used. | ||
126 | |||
127 | Element remove-project | ||
128 | ---------------------- | ||
129 | |||
130 | Deletes the named project from the internal manifest table, possibly | ||
131 | allowing a subsequent project element in the same manifest file to | ||
132 | replace the project with a different source. | ||
133 | |||
134 | This element is mostly useful in the local_manifest.xml, where | ||
135 | the user can remove a project, and possibly replace it with their | ||
136 | own definition. | ||
137 | |||
138 | |||
139 | Local Manifest | ||
140 | ============== | ||
141 | |||
142 | Additional remotes and projects may be added through a local | ||
143 | manifest, stored in `$TOP_DIR/.repo/local_manifest.xml`. | ||
144 | |||
145 | For example: | ||
146 | |||
147 | $ cat .repo/local_manifest.xml | ||
148 | <?xml version="1.0" encoding="UTF-8"?> | ||
149 | <manifest> | ||
150 | <project path="manifest" | ||
151 | name="tools/manifest" /> | ||
152 | <project path="platform-manifest" | ||
153 | name="platform/manifest" /> | ||
154 | </manifest> | ||
155 | |||
156 | Users may add projects to the local manifest prior to a `repo sync` | ||
157 | invocation, instructing repo to automatically download and manage | ||
158 | these extra projects. | ||