2008-11-04 19:19:36 +00:00
|
|
|
repo Manifest Format
|
|
|
|
|
====================
|
|
|
|
|
|
|
|
|
|
A repo manifest describes the structure of a repo client; that is
|
|
|
|
|
the directories that are visible and where they should be obtained
|
|
|
|
|
from with git.
|
|
|
|
|
|
|
|
|
|
The basic structure of a manifest is a bare Git repository holding
|
|
|
|
|
a single 'default.xml' XML file in the top level directory.
|
|
|
|
|
|
|
|
|
|
Manifests are inherently version controlled, since they are kept
|
|
|
|
|
within a Git repository. Updates to manifests are automatically
|
|
|
|
|
obtained by clients during `repo sync`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
XML File Format
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
A manifest XML file (e.g. 'default.xml') roughly conforms to the
|
|
|
|
|
following DTD:
|
|
|
|
|
|
2009-03-04 22:26:50 +00:00
|
|
|
<!DOCTYPE manifest [
|
2010-11-01 22:08:06 +00:00
|
|
|
<!ELEMENT manifest (notice?,
|
|
|
|
|
remote*,
|
2009-03-04 22:26:50 +00:00
|
|
|
default?,
|
2010-04-06 17:40:01 +00:00
|
|
|
manifest-server?,
|
2009-03-04 22:26:50 +00:00
|
|
|
remove-project*,
|
Support repo-level pre-upload hook and prep for future hooks.
All repo-level hooks are expected to live in a single project at the
top level of that project. The name of the hooks project is provided
in the manifest.xml. The manifest also lists which hooks are enabled
to make it obvious if a file somehow failed to sync down (or got
deleted).
Before running any hook, we will prompt the user to make sure that it
is OK. A user can deny running the hook, allow once, or allow
"forever" (until hooks change). This tries to keep with the git
spirit of not automatically running anything on the user's computer
that got synced down. Note that individual repo commands can add
always options to avoid these prompts as they see fit (see below for
the 'upload' options).
When hooks are run, they are loaded into the current interpreter (the
one running repo) and their main() function is run. This mechanism is
used (instead of using subprocess) to make it easier to expand to a
richer hook interface in the future. During loading, the
interpreter's sys.path is updated to contain the directory containing
the hooks so that hooks can be split into multiple files.
The upload command has two options that control hook behavior:
- no-verify=False, verify=False (DEFAULT):
If stdout is a tty, can prompt about running upload hooks if needed.
If user denies running hooks, the upload is cancelled. If stdout is
not a tty and we would need to prompt about upload hooks, upload is
cancelled.
- no-verify=False, verify=True:
Always run upload hooks with no prompt.
- no-verify=True, verify=False:
Never run upload hooks, but upload anyway (AKA bypass hooks).
- no-verify=True, verify=True:
Invalid
Sample bit of manifest.xml code for enabling hooks (assumes you have a
project named 'hooks' where hooks are stored):
<repo-hooks in-project="hooks" enabled-list="pre-upload" />
Sample main() function in pre-upload.py in hooks directory:
def main(project_list, **kwargs):
print ('These projects will be uploaded: %s' %
', '.join(project_list))
print ('I am being a good boy and ignoring anything in kwargs\n'
'that I don\'t understand.')
print 'I fail 50% of the time. How flaky.'
if random.random() <= .5:
raise Exception('Pre-upload hook failed. Have a nice day.')
Change-Id: I5cefa2cd5865c72589263cf8e2f152a43c122f70
2011-03-04 19:54:18 +00:00
|
|
|
project*,
|
|
|
|
|
repo-hooks?)>
|
2009-03-04 22:26:50 +00:00
|
|
|
|
2010-11-01 22:08:06 +00:00
|
|
|
<!ELEMENT notice (#PCDATA)>
|
|
|
|
|
|
2009-03-04 22:26:50 +00:00
|
|
|
<!ELEMENT remote (EMPTY)>
|
|
|
|
|
<!ATTLIST remote name ID #REQUIRED>
|
2012-07-02 14:32:50 +00:00
|
|
|
<!ATTLIST remote alias CDATA #IMPLIED>
|
2009-03-04 22:26:50 +00:00
|
|
|
<!ATTLIST remote fetch CDATA #REQUIRED>
|
|
|
|
|
<!ATTLIST remote review CDATA #IMPLIED>
|
|
|
|
|
|
|
|
|
|
<!ELEMENT default (EMPTY)>
|
|
|
|
|
<!ATTLIST default remote IDREF #IMPLIED>
|
|
|
|
|
<!ATTLIST default revision CDATA #IMPLIED>
|
2011-09-23 00:44:31 +00:00
|
|
|
<!ATTLIST default sync-j CDATA #IMPLIED>
|
2012-04-20 21:41:59 +00:00
|
|
|
<!ATTLIST default sync-c CDATA #IMPLIED>
|
Represent git-submodule as nested projects, take 2
(Previous submission of this change broke Android buildbot due to
incorrect regular expression for parsing git-config output. During
investigation, we also found that Android, which pulls Chromium, has a
workaround for Chromium's submodules; its manifest includes Chromium's
submodules. This new change, in addition to fixing the regex, also
take this type of workarounds into consideration; it adds a new
attribute that makes repo not fetch submodules unless submodules have a
project element defined in the manifest, or this attribute is
overridden by a parent project element or by the default element.)
We need a representation of git-submodule in repo; otherwise repo will
not sync submodules, and leave workspace in a broken state. Of course
this will not be a problem if all projects are owned by the owner of the
manifest file, who may simply choose not to use git-submodule in all
projects. However, this is not possible in practice because manifest
file owner is unlikely to own all upstream projects.
As git submodules are simply git repositories, it is natural to treat
them as plain repo projects that live inside a repo project. That is,
we could use recursively declared projects to denote the is-submodule
relation of git repositories.
The behavior of repo remains the same to projects that do not have a
sub-project within. As for parent projects, repo fetches them and their
sub-projects as normal projects, and then checks out subprojects at the
commit specified in parent's commit object. The sub-project is fetched
at a path relative to parent project's working directory; so the path
specified in manifest file should match that of .gitmodules file.
If a submodule is not registered in repo manifest, repo will derive its
properties from itself and its parent project, which might not always be
correct. In such cases, the subproject is called a derived subproject.
To a user, a sub-project is merely a git-submodule; so all tips of
working with a git-submodule apply here, too. For example, you should
not run `repo sync` in a parent repository if its submodule is dirty.
Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
2012-01-11 03:28:42 +00:00
|
|
|
<!ATTLIST default sync-s CDATA #IMPLIED>
|
2010-04-06 17:40:01 +00:00
|
|
|
|
|
|
|
|
<!ELEMENT manifest-server (EMPTY)>
|
|
|
|
|
<!ATTLIST url CDATA #REQUIRED>
|
2009-03-04 22:26:50 +00:00
|
|
|
|
Represent git-submodule as nested projects, take 2
(Previous submission of this change broke Android buildbot due to
incorrect regular expression for parsing git-config output. During
investigation, we also found that Android, which pulls Chromium, has a
workaround for Chromium's submodules; its manifest includes Chromium's
submodules. This new change, in addition to fixing the regex, also
take this type of workarounds into consideration; it adds a new
attribute that makes repo not fetch submodules unless submodules have a
project element defined in the manifest, or this attribute is
overridden by a parent project element or by the default element.)
We need a representation of git-submodule in repo; otherwise repo will
not sync submodules, and leave workspace in a broken state. Of course
this will not be a problem if all projects are owned by the owner of the
manifest file, who may simply choose not to use git-submodule in all
projects. However, this is not possible in practice because manifest
file owner is unlikely to own all upstream projects.
As git submodules are simply git repositories, it is natural to treat
them as plain repo projects that live inside a repo project. That is,
we could use recursively declared projects to denote the is-submodule
relation of git repositories.
The behavior of repo remains the same to projects that do not have a
sub-project within. As for parent projects, repo fetches them and their
sub-projects as normal projects, and then checks out subprojects at the
commit specified in parent's commit object. The sub-project is fetched
at a path relative to parent project's working directory; so the path
specified in manifest file should match that of .gitmodules file.
If a submodule is not registered in repo manifest, repo will derive its
properties from itself and its parent project, which might not always be
correct. In such cases, the subproject is called a derived subproject.
To a user, a sub-project is merely a git-submodule; so all tips of
working with a git-submodule apply here, too. For example, you should
not run `repo sync` in a parent repository if its submodule is dirty.
Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
2012-01-11 03:28:42 +00:00
|
|
|
<!ELEMENT project (annotation?,
|
|
|
|
|
project*)>
|
2009-03-04 22:26:50 +00:00
|
|
|
<!ATTLIST project name CDATA #REQUIRED>
|
|
|
|
|
<!ATTLIST project path CDATA #IMPLIED>
|
|
|
|
|
<!ATTLIST project remote IDREF #IMPLIED>
|
|
|
|
|
<!ATTLIST project revision CDATA #IMPLIED>
|
2012-03-29 03:15:45 +00:00
|
|
|
<!ATTLIST project groups CDATA #IMPLIED>
|
2012-04-20 21:41:59 +00:00
|
|
|
<!ATTLIST project sync-c CDATA #IMPLIED>
|
Represent git-submodule as nested projects, take 2
(Previous submission of this change broke Android buildbot due to
incorrect regular expression for parsing git-config output. During
investigation, we also found that Android, which pulls Chromium, has a
workaround for Chromium's submodules; its manifest includes Chromium's
submodules. This new change, in addition to fixing the regex, also
take this type of workarounds into consideration; it adds a new
attribute that makes repo not fetch submodules unless submodules have a
project element defined in the manifest, or this attribute is
overridden by a parent project element or by the default element.)
We need a representation of git-submodule in repo; otherwise repo will
not sync submodules, and leave workspace in a broken state. Of course
this will not be a problem if all projects are owned by the owner of the
manifest file, who may simply choose not to use git-submodule in all
projects. However, this is not possible in practice because manifest
file owner is unlikely to own all upstream projects.
As git submodules are simply git repositories, it is natural to treat
them as plain repo projects that live inside a repo project. That is,
we could use recursively declared projects to denote the is-submodule
relation of git repositories.
The behavior of repo remains the same to projects that do not have a
sub-project within. As for parent projects, repo fetches them and their
sub-projects as normal projects, and then checks out subprojects at the
commit specified in parent's commit object. The sub-project is fetched
at a path relative to parent project's working directory; so the path
specified in manifest file should match that of .gitmodules file.
If a submodule is not registered in repo manifest, repo will derive its
properties from itself and its parent project, which might not always be
correct. In such cases, the subproject is called a derived subproject.
To a user, a sub-project is merely a git-submodule; so all tips of
working with a git-submodule apply here, too. For example, you should
not run `repo sync` in a parent repository if its submodule is dirty.
Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
2012-01-11 03:28:42 +00:00
|
|
|
<!ATTLIST project sync-s CDATA #IMPLIED>
|
2012-11-27 13:20:10 +00:00
|
|
|
<!ATTLIST project upstream CDATA #IMPLIED>
|
2012-11-27 13:25:30 +00:00
|
|
|
<!ATTLIST project clone-depth CDATA #IMPLIED>
|
2013-02-28 01:34:14 +00:00
|
|
|
<!ATTLIST project force-path CDATA #IMPLIED>
|
2012-04-12 20:04:13 +00:00
|
|
|
|
|
|
|
|
<!ELEMENT annotation (EMPTY)>
|
|
|
|
|
<!ATTLIST annotation name CDATA #REQUIRED>
|
|
|
|
|
<!ATTLIST annotation value CDATA #REQUIRED>
|
|
|
|
|
<!ATTLIST annotation keep CDATA "true">
|
2009-03-04 22:26:50 +00:00
|
|
|
|
|
|
|
|
<!ELEMENT remove-project (EMPTY)>
|
|
|
|
|
<!ATTLIST remove-project name CDATA #REQUIRED>
|
Support repo-level pre-upload hook and prep for future hooks.
All repo-level hooks are expected to live in a single project at the
top level of that project. The name of the hooks project is provided
in the manifest.xml. The manifest also lists which hooks are enabled
to make it obvious if a file somehow failed to sync down (or got
deleted).
Before running any hook, we will prompt the user to make sure that it
is OK. A user can deny running the hook, allow once, or allow
"forever" (until hooks change). This tries to keep with the git
spirit of not automatically running anything on the user's computer
that got synced down. Note that individual repo commands can add
always options to avoid these prompts as they see fit (see below for
the 'upload' options).
When hooks are run, they are loaded into the current interpreter (the
one running repo) and their main() function is run. This mechanism is
used (instead of using subprocess) to make it easier to expand to a
richer hook interface in the future. During loading, the
interpreter's sys.path is updated to contain the directory containing
the hooks so that hooks can be split into multiple files.
The upload command has two options that control hook behavior:
- no-verify=False, verify=False (DEFAULT):
If stdout is a tty, can prompt about running upload hooks if needed.
If user denies running hooks, the upload is cancelled. If stdout is
not a tty and we would need to prompt about upload hooks, upload is
cancelled.
- no-verify=False, verify=True:
Always run upload hooks with no prompt.
- no-verify=True, verify=False:
Never run upload hooks, but upload anyway (AKA bypass hooks).
- no-verify=True, verify=True:
Invalid
Sample bit of manifest.xml code for enabling hooks (assumes you have a
project named 'hooks' where hooks are stored):
<repo-hooks in-project="hooks" enabled-list="pre-upload" />
Sample main() function in pre-upload.py in hooks directory:
def main(project_list, **kwargs):
print ('These projects will be uploaded: %s' %
', '.join(project_list))
print ('I am being a good boy and ignoring anything in kwargs\n'
'that I don\'t understand.')
print 'I fail 50% of the time. How flaky.'
if random.random() <= .5:
raise Exception('Pre-upload hook failed. Have a nice day.')
Change-Id: I5cefa2cd5865c72589263cf8e2f152a43c122f70
2011-03-04 19:54:18 +00:00
|
|
|
|
|
|
|
|
<!ELEMENT repo-hooks (EMPTY)>
|
|
|
|
|
<!ATTLIST repo-hooks in-project CDATA #REQUIRED>
|
|
|
|
|
<!ATTLIST repo-hooks enabled-list CDATA #REQUIRED>
|
2011-04-28 12:04:41 +00:00
|
|
|
|
|
|
|
|
<!ELEMENT include (EMPTY)>
|
|
|
|
|
<!ATTLIST include name CDATA #REQUIRED>
|
2009-03-04 22:26:50 +00:00
|
|
|
]>
|
2008-11-04 19:19:36 +00:00
|
|
|
|
|
|
|
|
A description of the elements and their attributes follows.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Element manifest
|
|
|
|
|
----------------
|
|
|
|
|
|
|
|
|
|
The root element of the file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Element remote
|
|
|
|
|
--------------
|
|
|
|
|
|
|
|
|
|
One or more remote elements may be specified. Each remote element
|
|
|
|
|
specifies a Git URL shared by one or more projects and (optionally)
|
|
|
|
|
the Gerrit review server those projects upload changes through.
|
|
|
|
|
|
|
|
|
|
Attribute `name`: A short name unique to this manifest file. The
|
|
|
|
|
name specified here is used as the remote name in each project's
|
|
|
|
|
.git/config, and is therefore automatically available to commands
|
|
|
|
|
like `git fetch`, `git remote`, `git pull` and `git push`.
|
|
|
|
|
|
2012-07-02 14:32:50 +00:00
|
|
|
Attribute `alias`: The alias, if specified, is used to override
|
|
|
|
|
`name` to be set as the remote name in each project's .git/config.
|
|
|
|
|
Its value can be duplicated while attribute `name` has to be unique
|
|
|
|
|
in the manifest file. This helps each project to be able to have
|
|
|
|
|
same remote name which actually points to different remote url.
|
|
|
|
|
|
2008-11-04 19:19:36 +00:00
|
|
|
Attribute `fetch`: The Git URL prefix for all projects which use
|
|
|
|
|
this remote. Each project's name is appended to this prefix to
|
|
|
|
|
form the actual URL used to clone the project.
|
|
|
|
|
|
|
|
|
|
Attribute `review`: Hostname of the Gerrit server where reviews
|
|
|
|
|
are uploaded to by `repo upload`. This attribute is optional;
|
|
|
|
|
if not specified then `repo upload` will not function.
|
|
|
|
|
|
|
|
|
|
Element default
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
At most one default element may be specified. Its remote and
|
|
|
|
|
revision attributes are used when a project element does not
|
|
|
|
|
specify its own remote or revision attribute.
|
|
|
|
|
|
|
|
|
|
Attribute `remote`: Name of a previously defined remote element.
|
|
|
|
|
Project elements lacking a remote attribute of their own will use
|
|
|
|
|
this remote.
|
|
|
|
|
|
|
|
|
|
Attribute `revision`: Name of a Git branch (e.g. `master` or
|
|
|
|
|
`refs/heads/master`). Project elements lacking their own
|
|
|
|
|
revision attribute will use this revision.
|
|
|
|
|
|
2012-11-27 13:20:10 +00:00
|
|
|
Attribute `sync_j`: Number of parallel jobs to use when synching.
|
|
|
|
|
|
|
|
|
|
Attribute `sync_c`: Set to true to only sync the given Git
|
|
|
|
|
branch (specified in the `revision` attribute) rather than the
|
|
|
|
|
whole ref space. Project elements lacking a sync_c element of
|
|
|
|
|
their own will use this value.
|
|
|
|
|
|
|
|
|
|
Attribute `sync_s`: Set to true to also sync sub-projects.
|
|
|
|
|
|
2008-11-04 19:19:36 +00:00
|
|
|
|
2010-04-06 17:40:01 +00:00
|
|
|
Element manifest-server
|
|
|
|
|
-----------------------
|
|
|
|
|
|
|
|
|
|
At most one manifest-server may be specified. The url attribute
|
|
|
|
|
is used to specify the URL of a manifest server, which is an
|
2012-08-21 05:23:49 +00:00
|
|
|
XML RPC service.
|
2010-04-06 17:40:01 +00:00
|
|
|
|
2012-08-21 05:23:49 +00:00
|
|
|
The manifest server should implement the following RPC methods:
|
2010-04-06 17:40:01 +00:00
|
|
|
|
|
|
|
|
GetApprovedManifest(branch, target)
|
|
|
|
|
|
2012-08-21 05:23:49 +00:00
|
|
|
Return a manifest in which each project is pegged to a known good revision
|
|
|
|
|
for the current branch and target.
|
|
|
|
|
|
2010-04-06 17:40:01 +00:00
|
|
|
The target to use is defined by environment variables TARGET_PRODUCT
|
|
|
|
|
and TARGET_BUILD_VARIANT. These variables are used to create a string
|
|
|
|
|
of the form $TARGET_PRODUCT-$TARGET_BUILD_VARIANT, e.g. passion-userdebug.
|
|
|
|
|
If one of those variables or both are not present, the program will call
|
2012-08-21 04:52:18 +00:00
|
|
|
GetApprovedManifest without the target parameter and the manifest server
|
2010-04-06 17:40:01 +00:00
|
|
|
should choose a reasonable default target.
|
|
|
|
|
|
2012-08-21 05:23:49 +00:00
|
|
|
GetManifest(tag)
|
|
|
|
|
|
|
|
|
|
Return a manifest in which each project is pegged to the revision at
|
|
|
|
|
the specified tag.
|
|
|
|
|
|
2010-04-06 17:40:01 +00:00
|
|
|
|
2008-11-04 19:19:36 +00:00
|
|
|
Element project
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
One or more project elements may be specified. Each element
|
|
|
|
|
describes a single Git repository to be cloned into the repo
|
Represent git-submodule as nested projects, take 2
(Previous submission of this change broke Android buildbot due to
incorrect regular expression for parsing git-config output. During
investigation, we also found that Android, which pulls Chromium, has a
workaround for Chromium's submodules; its manifest includes Chromium's
submodules. This new change, in addition to fixing the regex, also
take this type of workarounds into consideration; it adds a new
attribute that makes repo not fetch submodules unless submodules have a
project element defined in the manifest, or this attribute is
overridden by a parent project element or by the default element.)
We need a representation of git-submodule in repo; otherwise repo will
not sync submodules, and leave workspace in a broken state. Of course
this will not be a problem if all projects are owned by the owner of the
manifest file, who may simply choose not to use git-submodule in all
projects. However, this is not possible in practice because manifest
file owner is unlikely to own all upstream projects.
As git submodules are simply git repositories, it is natural to treat
them as plain repo projects that live inside a repo project. That is,
we could use recursively declared projects to denote the is-submodule
relation of git repositories.
The behavior of repo remains the same to projects that do not have a
sub-project within. As for parent projects, repo fetches them and their
sub-projects as normal projects, and then checks out subprojects at the
commit specified in parent's commit object. The sub-project is fetched
at a path relative to parent project's working directory; so the path
specified in manifest file should match that of .gitmodules file.
If a submodule is not registered in repo manifest, repo will derive its
properties from itself and its parent project, which might not always be
correct. In such cases, the subproject is called a derived subproject.
To a user, a sub-project is merely a git-submodule; so all tips of
working with a git-submodule apply here, too. For example, you should
not run `repo sync` in a parent repository if its submodule is dirty.
Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
2012-01-11 03:28:42 +00:00
|
|
|
client workspace. You may specify Git-submodules by creating a
|
|
|
|
|
nested project. Git-submodules will be automatically
|
|
|
|
|
recognized and inherit their parent's attributes, but those
|
|
|
|
|
may be overridden by an explicitly specified project element.
|
2008-11-04 19:19:36 +00:00
|
|
|
|
|
|
|
|
Attribute `name`: A unique name for this project. The project's
|
|
|
|
|
name is appended onto its remote's fetch URL to generate the actual
|
|
|
|
|
URL to configure the Git remote with. The URL gets formed as:
|
|
|
|
|
|
|
|
|
|
${remote_fetch}/${project_name}.git
|
|
|
|
|
|
|
|
|
|
where ${remote_fetch} is the remote's fetch attribute and
|
|
|
|
|
${project_name} is the project's name attribute. The suffix ".git"
|
2012-08-21 04:52:18 +00:00
|
|
|
is always appended as repo assumes the upstream is a forest of
|
Represent git-submodule as nested projects, take 2
(Previous submission of this change broke Android buildbot due to
incorrect regular expression for parsing git-config output. During
investigation, we also found that Android, which pulls Chromium, has a
workaround for Chromium's submodules; its manifest includes Chromium's
submodules. This new change, in addition to fixing the regex, also
take this type of workarounds into consideration; it adds a new
attribute that makes repo not fetch submodules unless submodules have a
project element defined in the manifest, or this attribute is
overridden by a parent project element or by the default element.)
We need a representation of git-submodule in repo; otherwise repo will
not sync submodules, and leave workspace in a broken state. Of course
this will not be a problem if all projects are owned by the owner of the
manifest file, who may simply choose not to use git-submodule in all
projects. However, this is not possible in practice because manifest
file owner is unlikely to own all upstream projects.
As git submodules are simply git repositories, it is natural to treat
them as plain repo projects that live inside a repo project. That is,
we could use recursively declared projects to denote the is-submodule
relation of git repositories.
The behavior of repo remains the same to projects that do not have a
sub-project within. As for parent projects, repo fetches them and their
sub-projects as normal projects, and then checks out subprojects at the
commit specified in parent's commit object. The sub-project is fetched
at a path relative to parent project's working directory; so the path
specified in manifest file should match that of .gitmodules file.
If a submodule is not registered in repo manifest, repo will derive its
properties from itself and its parent project, which might not always be
correct. In such cases, the subproject is called a derived subproject.
To a user, a sub-project is merely a git-submodule; so all tips of
working with a git-submodule apply here, too. For example, you should
not run `repo sync` in a parent repository if its submodule is dirty.
Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
2012-01-11 03:28:42 +00:00
|
|
|
bare Git repositories. If the project has a parent element, its
|
|
|
|
|
name will be prefixed by the parent's.
|
2008-11-04 19:19:36 +00:00
|
|
|
|
|
|
|
|
The project name must match the name Gerrit knows, if Gerrit is
|
|
|
|
|
being used for code reviews.
|
|
|
|
|
|
|
|
|
|
Attribute `path`: An optional path relative to the top directory
|
|
|
|
|
of the repo client where the Git working directory for this project
|
|
|
|
|
should be placed. If not supplied the project name is used.
|
Represent git-submodule as nested projects, take 2
(Previous submission of this change broke Android buildbot due to
incorrect regular expression for parsing git-config output. During
investigation, we also found that Android, which pulls Chromium, has a
workaround for Chromium's submodules; its manifest includes Chromium's
submodules. This new change, in addition to fixing the regex, also
take this type of workarounds into consideration; it adds a new
attribute that makes repo not fetch submodules unless submodules have a
project element defined in the manifest, or this attribute is
overridden by a parent project element or by the default element.)
We need a representation of git-submodule in repo; otherwise repo will
not sync submodules, and leave workspace in a broken state. Of course
this will not be a problem if all projects are owned by the owner of the
manifest file, who may simply choose not to use git-submodule in all
projects. However, this is not possible in practice because manifest
file owner is unlikely to own all upstream projects.
As git submodules are simply git repositories, it is natural to treat
them as plain repo projects that live inside a repo project. That is,
we could use recursively declared projects to denote the is-submodule
relation of git repositories.
The behavior of repo remains the same to projects that do not have a
sub-project within. As for parent projects, repo fetches them and their
sub-projects as normal projects, and then checks out subprojects at the
commit specified in parent's commit object. The sub-project is fetched
at a path relative to parent project's working directory; so the path
specified in manifest file should match that of .gitmodules file.
If a submodule is not registered in repo manifest, repo will derive its
properties from itself and its parent project, which might not always be
correct. In such cases, the subproject is called a derived subproject.
To a user, a sub-project is merely a git-submodule; so all tips of
working with a git-submodule apply here, too. For example, you should
not run `repo sync` in a parent repository if its submodule is dirty.
Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
2012-01-11 03:28:42 +00:00
|
|
|
If the project has a parent element, its path will be prefixed
|
|
|
|
|
by the parent's.
|
2008-11-04 19:19:36 +00:00
|
|
|
|
|
|
|
|
Attribute `remote`: Name of a previously defined remote element.
|
|
|
|
|
If not supplied the remote given by the default element is used.
|
|
|
|
|
|
|
|
|
|
Attribute `revision`: Name of the Git branch the manifest wants
|
|
|
|
|
to track for this project. Names can be relative to refs/heads
|
|
|
|
|
(e.g. just "master") or absolute (e.g. "refs/heads/master").
|
|
|
|
|
Tags and/or explicit SHA-1s should work in theory, but have not
|
|
|
|
|
been extensively tested. If not supplied the revision given by
|
|
|
|
|
the default element is used.
|
|
|
|
|
|
2012-03-29 03:15:45 +00:00
|
|
|
Attribute `groups`: List of groups to which this project belongs,
|
2012-04-16 17:36:08 +00:00
|
|
|
whitespace or comma separated. All projects belong to the group
|
2012-08-13 20:11:18 +00:00
|
|
|
"all", and each project automatically belongs to a group of
|
|
|
|
|
its name:`name` and path:`path`. E.g. for
|
2012-06-15 09:24:20 +00:00
|
|
|
<project name="monkeys" path="barrel-of"/>, that project
|
|
|
|
|
definition is implicitly in the following manifest groups:
|
2012-08-13 20:11:18 +00:00
|
|
|
default, name:monkeys, and path:barrel-of. If you place a project in the
|
|
|
|
|
group "notdefault", it will not be automatically downloaded by repo.
|
Represent git-submodule as nested projects, take 2
(Previous submission of this change broke Android buildbot due to
incorrect regular expression for parsing git-config output. During
investigation, we also found that Android, which pulls Chromium, has a
workaround for Chromium's submodules; its manifest includes Chromium's
submodules. This new change, in addition to fixing the regex, also
take this type of workarounds into consideration; it adds a new
attribute that makes repo not fetch submodules unless submodules have a
project element defined in the manifest, or this attribute is
overridden by a parent project element or by the default element.)
We need a representation of git-submodule in repo; otherwise repo will
not sync submodules, and leave workspace in a broken state. Of course
this will not be a problem if all projects are owned by the owner of the
manifest file, who may simply choose not to use git-submodule in all
projects. However, this is not possible in practice because manifest
file owner is unlikely to own all upstream projects.
As git submodules are simply git repositories, it is natural to treat
them as plain repo projects that live inside a repo project. That is,
we could use recursively declared projects to denote the is-submodule
relation of git repositories.
The behavior of repo remains the same to projects that do not have a
sub-project within. As for parent projects, repo fetches them and their
sub-projects as normal projects, and then checks out subprojects at the
commit specified in parent's commit object. The sub-project is fetched
at a path relative to parent project's working directory; so the path
specified in manifest file should match that of .gitmodules file.
If a submodule is not registered in repo manifest, repo will derive its
properties from itself and its parent project, which might not always be
correct. In such cases, the subproject is called a derived subproject.
To a user, a sub-project is merely a git-submodule; so all tips of
working with a git-submodule apply here, too. For example, you should
not run `repo sync` in a parent repository if its submodule is dirty.
Change-Id: I4b8344c1b9ccad2f58ad304573133e5d52e1faef
2012-01-11 03:28:42 +00:00
|
|
|
If the project has a parent element, the `name` and `path` here
|
|
|
|
|
are the prefixed ones.
|
2012-03-29 03:15:45 +00:00
|
|
|
|
2012-11-27 13:20:10 +00:00
|
|
|
Attribute `sync_c`: Set to true to only sync the given Git
|
|
|
|
|
branch (specified in the `revision` attribute) rather than the
|
|
|
|
|
whole ref space.
|
|
|
|
|
|
|
|
|
|
Attribute `sync_s`: Set to true to also sync sub-projects.
|
|
|
|
|
|
|
|
|
|
Attribute `upstream`: Name of the Git branch in which a sha1
|
|
|
|
|
can be found. Used when syncing a revision locked manifest in
|
|
|
|
|
-c mode to avoid having to sync the entire ref space.
|
|
|
|
|
|
2012-11-27 13:25:30 +00:00
|
|
|
Attribute `clone-depth`: Set the depth to use when fetching this
|
|
|
|
|
project. If specified, this value will override any value given
|
|
|
|
|
to repo init with the --depth option on the command line.
|
|
|
|
|
|
2013-02-28 01:34:14 +00:00
|
|
|
Attribute `force-path`: Set to true to force this project to create the
|
|
|
|
|
local mirror repository according to its `path` attribute (if supplied)
|
|
|
|
|
rather than the `name` attribute. This attribute only applies to the
|
|
|
|
|
local mirrors syncing, it will be ignored when syncing the projects in a
|
|
|
|
|
client working directory.
|
|
|
|
|
|
2012-04-12 20:04:13 +00:00
|
|
|
Element annotation
|
|
|
|
|
------------------
|
|
|
|
|
|
|
|
|
|
Zero or more annotation elements may be specified as children of a
|
|
|
|
|
project element. Each element describes a name-value pair that will be
|
|
|
|
|
exported into each project's environment during a 'forall' command,
|
|
|
|
|
prefixed with REPO__. In addition, there is an optional attribute
|
|
|
|
|
"keep" which accepts the case insensitive values "true" (default) or
|
|
|
|
|
"false". This attribute determines whether or not the annotation will
|
|
|
|
|
be kept when exported with the manifest subcommand.
|
|
|
|
|
|
2008-11-20 19:42:22 +00:00
|
|
|
Element remove-project
|
|
|
|
|
----------------------
|
|
|
|
|
|
|
|
|
|
Deletes the named project from the internal manifest table, possibly
|
|
|
|
|
allowing a subsequent project element in the same manifest file to
|
|
|
|
|
replace the project with a different source.
|
|
|
|
|
|
2012-11-13 23:51:38 +00:00
|
|
|
This element is mostly useful in a local manifest file, where
|
2008-11-20 19:42:22 +00:00
|
|
|
the user can remove a project, and possibly replace it with their
|
|
|
|
|
own definition.
|
|
|
|
|
|
2011-04-28 12:04:41 +00:00
|
|
|
Element include
|
|
|
|
|
---------------
|
|
|
|
|
|
|
|
|
|
This element provides the capability of including another manifest
|
|
|
|
|
file into the originating manifest. Normal rules apply for the
|
2012-11-13 23:52:25 +00:00
|
|
|
target manifest to include - it must be a usable manifest on its own.
|
2011-04-28 12:04:41 +00:00
|
|
|
|
2012-11-13 23:52:25 +00:00
|
|
|
Attribute `name`: the manifest to include, specified relative to
|
|
|
|
|
the manifest repository's root.
|
2011-04-28 12:04:41 +00:00
|
|
|
|
2008-11-20 19:42:22 +00:00
|
|
|
|
2012-11-12 17:50:36 +00:00
|
|
|
Local Manifests
|
|
|
|
|
===============
|
2008-11-06 16:48:44 +00:00
|
|
|
|
2012-11-12 17:50:36 +00:00
|
|
|
Additional remotes and projects may be added through local manifest
|
|
|
|
|
files stored in `$TOP_DIR/.repo/local_manifests/*.xml`.
|
2008-11-06 16:48:44 +00:00
|
|
|
|
|
|
|
|
For example:
|
|
|
|
|
|
2012-11-12 17:50:36 +00:00
|
|
|
$ ls .repo/local_manifests
|
|
|
|
|
local_manifest.xml
|
|
|
|
|
another_local_manifest.xml
|
|
|
|
|
|
|
|
|
|
$ cat .repo/local_manifests/local_manifest.xml
|
2009-03-04 22:26:50 +00:00
|
|
|
<?xml version="1.0" encoding="UTF-8"?>
|
|
|
|
|
<manifest>
|
|
|
|
|
<project path="manifest"
|
|
|
|
|
name="tools/manifest" />
|
|
|
|
|
<project path="platform-manifest"
|
|
|
|
|
name="platform/manifest" />
|
|
|
|
|
</manifest>
|
2008-11-06 16:48:44 +00:00
|
|
|
|
2012-11-12 17:50:36 +00:00
|
|
|
Users may add projects to the local manifest(s) prior to a `repo sync`
|
2008-11-06 16:48:44 +00:00
|
|
|
invocation, instructing repo to automatically download and manage
|
|
|
|
|
these extra projects.
|
2012-11-12 17:50:36 +00:00
|
|
|
|
2012-11-13 19:53:24 +00:00
|
|
|
Manifest files stored in `$TOP_DIR/.repo/local_manifests/*.xml` will
|
|
|
|
|
be loaded in alphabetical order.
|
|
|
|
|
|
2012-11-12 17:50:36 +00:00
|
|
|
Additional remotes and projects may also be added through a local
|
2012-11-12 18:04:18 +00:00
|
|
|
manifest, stored in `$TOP_DIR/.repo/local_manifest.xml`. This method
|
|
|
|
|
is deprecated in favor of using multiple manifest files as mentioned
|
|
|
|
|
above.
|
2012-11-13 19:53:24 +00:00
|
|
|
|
|
|
|
|
If `$TOP_DIR/.repo/local_manifest.xml` exists, it will be loaded before
|
|
|
|
|
any manifest files stored in `$TOP_DIR/.repo/local_manifests/*.xml`.
|
