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