manifest-format.txt 6.5 KB

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