2008-10-21 14:00:00 +00:00
|
|
|
#
|
|
|
|
# Copyright (C) 2008 The Android Open Source Project
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
|
2012-11-02 05:59:27 +00:00
|
|
|
from __future__ import print_function
|
2012-04-21 07:33:54 +00:00
|
|
|
import itertools
|
2008-10-21 14:00:00 +00:00
|
|
|
import os
|
2011-09-26 23:34:01 +00:00
|
|
|
import re
|
2008-10-21 14:00:00 +00:00
|
|
|
import sys
|
2013-05-17 01:49:33 +00:00
|
|
|
import xml.dom.minidom
|
|
|
|
|
|
|
|
from pyversion import is_python3
|
|
|
|
if is_python3():
|
2013-03-01 13:44:38 +00:00
|
|
|
import urllib.parse
|
2013-05-17 01:49:33 +00:00
|
|
|
else:
|
2013-03-01 13:44:38 +00:00
|
|
|
import imp
|
|
|
|
import urlparse
|
|
|
|
urllib = imp.new_module('urllib')
|
2013-06-11 08:12:25 +00:00
|
|
|
urllib.parse = urlparse
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2012-08-22 01:46:11 +00:00
|
|
|
from git_config import GitConfig
|
2012-09-11 05:33:51 +00:00
|
|
|
from git_refs import R_HEADS, HEAD
|
|
|
|
from project import RemoteSpec, Project, MetaProject
|
2014-01-09 15:21:37 +00:00
|
|
|
from error import ManifestParseError, ManifestInvalidRevisionError
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
MANIFEST_FILE_NAME = 'manifest.xml'
|
2008-10-23 23:19:27 +00:00
|
|
|
LOCAL_MANIFEST_NAME = 'local_manifest.xml'
|
2012-11-12 17:50:36 +00:00
|
|
|
LOCAL_MANIFESTS_DIR_NAME = 'local_manifests'
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2015-03-28 23:26:04 +00:00
|
|
|
# urljoin gets confused if the scheme is not known.
|
|
|
|
urllib.parse.uses_relative.extend(['ssh', 'git', 'persistent-https', 'rpc'])
|
|
|
|
urllib.parse.uses_netloc.extend(['ssh', 'git', 'persistent-https', 'rpc'])
|
2011-09-26 23:34:01 +00:00
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
class _Default(object):
|
|
|
|
"""Project defaults within the manifest."""
|
|
|
|
|
2009-05-30 01:38:17 +00:00
|
|
|
revisionExpr = None
|
2013-09-25 22:06:09 +00:00
|
|
|
destBranchExpr = None
|
2008-10-21 14:00:00 +00:00
|
|
|
remote = None
|
2011-09-23 00:44:31 +00:00
|
|
|
sync_j = 1
|
2012-04-20 21:41:59 +00:00
|
|
|
sync_c = False
|
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
|
|
|
sync_s = False
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2013-10-09 12:38:46 +00:00
|
|
|
def __eq__(self, other):
|
|
|
|
return self.__dict__ == other.__dict__
|
|
|
|
|
|
|
|
def __ne__(self, other):
|
|
|
|
return self.__dict__ != other.__dict__
|
|
|
|
|
2009-05-19 21:58:02 +00:00
|
|
|
class _XmlRemote(object):
|
|
|
|
def __init__(self,
|
|
|
|
name,
|
2012-07-02 14:32:50 +00:00
|
|
|
alias=None,
|
2009-05-19 21:58:02 +00:00
|
|
|
fetch=None,
|
2011-09-26 23:34:01 +00:00
|
|
|
manifestUrl=None,
|
2014-05-06 10:54:01 +00:00
|
|
|
review=None,
|
2015-03-17 18:29:58 +00:00
|
|
|
revision=None):
|
2009-05-19 21:58:02 +00:00
|
|
|
self.name = name
|
|
|
|
self.fetchUrl = fetch
|
2011-09-26 23:34:01 +00:00
|
|
|
self.manifestUrl = manifestUrl
|
2012-07-02 14:32:50 +00:00
|
|
|
self.remoteAlias = alias
|
2009-05-19 21:58:02 +00:00
|
|
|
self.reviewUrl = review
|
2014-05-06 10:54:01 +00:00
|
|
|
self.revision = revision
|
2011-10-20 17:45:47 +00:00
|
|
|
self.resolvedFetchUrl = self._resolveFetchUrl()
|
2009-05-19 21:58:02 +00:00
|
|
|
|
2012-11-12 23:49:16 +00:00
|
|
|
def __eq__(self, other):
|
|
|
|
return self.__dict__ == other.__dict__
|
|
|
|
|
|
|
|
def __ne__(self, other):
|
|
|
|
return self.__dict__ != other.__dict__
|
|
|
|
|
2011-10-20 17:45:47 +00:00
|
|
|
def _resolveFetchUrl(self):
|
|
|
|
url = self.fetchUrl.rstrip('/')
|
2011-09-26 23:34:01 +00:00
|
|
|
manifestUrl = self.manifestUrl.rstrip('/')
|
2014-01-31 23:03:51 +00:00
|
|
|
# urljoin will gets confused over quite a few things. The ones we care
|
|
|
|
# about here are:
|
|
|
|
# * no scheme in the base url, like <hostname:port>
|
2015-03-28 23:26:04 +00:00
|
|
|
# We handle no scheme by replacing it with an obscure protocol, gopher
|
|
|
|
# and then replacing it with the original when we are done.
|
|
|
|
|
2011-09-26 23:34:01 +00:00
|
|
|
if manifestUrl.find(':') != manifestUrl.find('/') - 1:
|
2015-04-29 17:45:37 +00:00
|
|
|
url = urllib.parse.urljoin('gopher://' + manifestUrl, url)
|
|
|
|
url = re.sub(r'^gopher://', '', url)
|
2015-03-28 23:26:04 +00:00
|
|
|
else:
|
|
|
|
url = urllib.parse.urljoin(manifestUrl, url)
|
2013-01-02 23:40:48 +00:00
|
|
|
return url
|
2011-10-20 17:45:47 +00:00
|
|
|
|
|
|
|
def ToRemoteSpec(self, projectName):
|
2011-10-20 21:36:35 +00:00
|
|
|
url = self.resolvedFetchUrl.rstrip('/') + '/' + projectName
|
2012-07-02 14:32:50 +00:00
|
|
|
remoteName = self.name
|
2013-10-09 00:26:57 +00:00
|
|
|
if self.remoteAlias:
|
2013-10-15 01:48:40 +00:00
|
|
|
remoteName = self.remoteAlias
|
2012-07-02 14:32:50 +00:00
|
|
|
return RemoteSpec(remoteName, url, self.reviewUrl)
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2009-05-18 20:19:57 +00:00
|
|
|
class XmlManifest(object):
|
2008-10-21 14:00:00 +00:00
|
|
|
"""manages the repo configuration file"""
|
|
|
|
|
|
|
|
def __init__(self, repodir):
|
|
|
|
self.repodir = os.path.abspath(repodir)
|
|
|
|
self.topdir = os.path.dirname(self.repodir)
|
|
|
|
self.manifestFile = os.path.join(self.repodir, MANIFEST_FILE_NAME)
|
|
|
|
self.globalConfig = GitConfig.ForUser()
|
2013-02-14 07:28:44 +00:00
|
|
|
self.localManifestWarning = False
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
self.repoProject = MetaProject(self, 'repo',
|
|
|
|
gitdir = os.path.join(repodir, 'repo/.git'),
|
|
|
|
worktree = os.path.join(repodir, 'repo'))
|
|
|
|
|
|
|
|
self.manifestProject = MetaProject(self, 'manifests',
|
2008-11-04 16:11:53 +00:00
|
|
|
gitdir = os.path.join(repodir, 'manifests.git'),
|
|
|
|
worktree = os.path.join(repodir, 'manifests'))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
self._Unload()
|
|
|
|
|
2010-04-06 17:40:01 +00:00
|
|
|
def Override(self, name):
|
|
|
|
"""Use a different manifest, just for the current instantiation.
|
2008-10-21 14:00:00 +00:00
|
|
|
"""
|
|
|
|
path = os.path.join(self.manifestProject.worktree, name)
|
|
|
|
if not os.path.isfile(path):
|
|
|
|
raise ManifestParseError('manifest %s not found' % name)
|
|
|
|
|
|
|
|
old = self.manifestFile
|
|
|
|
try:
|
|
|
|
self.manifestFile = path
|
|
|
|
self._Unload()
|
|
|
|
self._Load()
|
|
|
|
finally:
|
|
|
|
self.manifestFile = old
|
|
|
|
|
2010-04-06 17:40:01 +00:00
|
|
|
def Link(self, name):
|
|
|
|
"""Update the repo metadata to use a different manifest.
|
|
|
|
"""
|
|
|
|
self.Override(name)
|
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
try:
|
2012-11-21 18:09:25 +00:00
|
|
|
if os.path.lexists(self.manifestFile):
|
2008-10-21 14:00:00 +00:00
|
|
|
os.remove(self.manifestFile)
|
|
|
|
os.symlink('manifests/%s' % name, self.manifestFile)
|
2012-11-21 18:09:25 +00:00
|
|
|
except OSError as e:
|
|
|
|
raise ManifestParseError('cannot link manifest %s: %s' % (name, str(e)))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2009-03-05 18:32:38 +00:00
|
|
|
def _RemoteToXml(self, r, doc, root):
|
|
|
|
e = doc.createElement('remote')
|
|
|
|
root.appendChild(e)
|
|
|
|
e.setAttribute('name', r.name)
|
|
|
|
e.setAttribute('fetch', r.fetchUrl)
|
2013-10-09 00:26:57 +00:00
|
|
|
if r.remoteAlias is not None:
|
|
|
|
e.setAttribute('alias', r.remoteAlias)
|
2009-03-05 18:32:38 +00:00
|
|
|
if r.reviewUrl is not None:
|
|
|
|
e.setAttribute('review', r.reviewUrl)
|
2014-05-06 10:54:01 +00:00
|
|
|
if r.revision is not None:
|
|
|
|
e.setAttribute('revision', r.revision)
|
2009-03-05 18:32:38 +00:00
|
|
|
|
2014-06-12 21:57:29 +00:00
|
|
|
def _ParseGroups(self, groups):
|
|
|
|
return [x for x in re.split(r'[,\s]+', groups) if x]
|
|
|
|
|
2012-09-29 03:21:57 +00:00
|
|
|
def Save(self, fd, peg_rev=False, peg_rev_upstream=True):
|
2009-03-05 18:32:38 +00:00
|
|
|
"""Write the current manifest out to the given file descriptor.
|
|
|
|
"""
|
2012-03-29 03:15:45 +00:00
|
|
|
mp = self.manifestProject
|
|
|
|
|
|
|
|
groups = mp.config.GetString('manifest.groups')
|
Make -notdefault a default manifest group
When trying to render manifest with SHAs, projects in group notdefault
caused the following crash:
Traceback (most recent call last):
File ".repo/repo/main.py", line 385, in <module>
_Main(sys.argv[1:])
File ".repo/repo/main.py", line 365, in _Main
result = repo._Run(argv) or 0
File ".repo/repo/main.py", line 137, in _Run
result = cmd.Execute(copts, cargs)
File ".repo/repo/subcmds/manifest.py", line 129, in Execute
self._Output(opt, manifest)
File ".repo/repo/subcmds/manifest.py", line 79, in _Output
peg_rev = opt.peg_rev)
File ".repo/repo/manifest_xml.py", line 199, in Save
p.work_git.rev_parse(HEAD + '^0'))
File ".repo/repo/project.py", line 2035, in runner
capture_stderr = True)
File ".repo/repo/git_command.py", line 215, in __init__
raise GitError('%s: %s' % (command[1], e))
error.GitError: rev-parse: [Errno 2] No such file or directory: 'prebuilts/eclipse-build-deps'
This patch resolves the issue by making sure that -notdefault is always
used as a default manifest group so that notdefault projects are not
rendered out by the manifest subcmd.
Change-Id: I4a8bd18ea7600309f39ceff1b1ab6e1ff3adf21d
Signed-off-by: Matt Gumbel <matthew.k.gumbel@intel.com>
2012-12-21 18:14:53 +00:00
|
|
|
if groups:
|
2014-06-12 21:57:29 +00:00
|
|
|
groups = self._ParseGroups(groups)
|
2012-03-29 03:15:45 +00:00
|
|
|
|
2009-03-05 18:32:38 +00:00
|
|
|
doc = xml.dom.minidom.Document()
|
|
|
|
root = doc.createElement('manifest')
|
|
|
|
doc.appendChild(root)
|
|
|
|
|
2010-11-01 22:08:06 +00:00
|
|
|
# Save out the notice. There's a little bit of work here to give it the
|
|
|
|
# right whitespace, which assumes that the notice is automatically indented
|
|
|
|
# by 4 by minidom.
|
|
|
|
if self.notice:
|
|
|
|
notice_element = root.appendChild(doc.createElement('notice'))
|
|
|
|
notice_lines = self.notice.splitlines()
|
|
|
|
indented_notice = ('\n'.join(" "*4 + line for line in notice_lines))[4:]
|
|
|
|
notice_element.appendChild(doc.createTextNode(indented_notice))
|
|
|
|
|
2009-03-05 18:32:38 +00:00
|
|
|
d = self.default
|
|
|
|
|
2013-03-01 13:44:38 +00:00
|
|
|
for r in sorted(self.remotes):
|
2009-03-05 18:32:38 +00:00
|
|
|
self._RemoteToXml(self.remotes[r], doc, root)
|
|
|
|
if self.remotes:
|
|
|
|
root.appendChild(doc.createTextNode(''))
|
|
|
|
|
|
|
|
have_default = False
|
|
|
|
e = doc.createElement('default')
|
|
|
|
if d.remote:
|
|
|
|
have_default = True
|
|
|
|
e.setAttribute('remote', d.remote.name)
|
2009-05-30 01:38:17 +00:00
|
|
|
if d.revisionExpr:
|
2009-03-05 18:32:38 +00:00
|
|
|
have_default = True
|
2009-05-30 01:38:17 +00:00
|
|
|
e.setAttribute('revision', d.revisionExpr)
|
2015-07-24 10:50:06 +00:00
|
|
|
if d.destBranchExpr:
|
|
|
|
have_default = True
|
|
|
|
e.setAttribute('dest-branch', d.destBranchExpr)
|
2011-09-23 00:44:31 +00:00
|
|
|
if d.sync_j > 1:
|
|
|
|
have_default = True
|
|
|
|
e.setAttribute('sync-j', '%d' % d.sync_j)
|
2012-04-20 21:41:59 +00:00
|
|
|
if d.sync_c:
|
|
|
|
have_default = True
|
|
|
|
e.setAttribute('sync-c', 'true')
|
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 d.sync_s:
|
|
|
|
have_default = True
|
|
|
|
e.setAttribute('sync-s', 'true')
|
2009-03-05 18:32:38 +00:00
|
|
|
if have_default:
|
|
|
|
root.appendChild(e)
|
|
|
|
root.appendChild(doc.createTextNode(''))
|
|
|
|
|
2010-04-06 17:40:01 +00:00
|
|
|
if self._manifest_server:
|
|
|
|
e = doc.createElement('manifest-server')
|
|
|
|
e.setAttribute('url', self._manifest_server)
|
|
|
|
root.appendChild(e)
|
|
|
|
root.appendChild(doc.createTextNode(''))
|
|
|
|
|
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
|
|
|
def output_projects(parent, parent_node, projects):
|
2013-10-12 00:03:19 +00:00
|
|
|
for project_name in projects:
|
|
|
|
for project in self._projects[project_name]:
|
|
|
|
output_project(parent, parent_node, project)
|
Represent git-submodule as nested projects
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: I541e9e2ac1a70304272dbe09724572aa1004eb5c
2012-01-11 03:28:42 +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
|
|
|
def output_project(parent, parent_node, p):
|
2012-10-26 19:18:00 +00:00
|
|
|
if not p.MatchesGroups(groups):
|
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
|
|
|
return
|
|
|
|
|
|
|
|
name = p.name
|
|
|
|
relpath = p.relpath
|
|
|
|
if parent:
|
|
|
|
name = self._UnjoinName(parent.name, name)
|
|
|
|
relpath = self._UnjoinRelpath(parent.relpath, relpath)
|
2012-03-29 03:15:45 +00:00
|
|
|
|
2009-03-05 18:32:38 +00:00
|
|
|
e = doc.createElement('project')
|
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
|
|
|
parent_node.appendChild(e)
|
|
|
|
e.setAttribute('name', name)
|
|
|
|
if relpath != name:
|
|
|
|
e.setAttribute('path', relpath)
|
2013-10-16 21:38:09 +00:00
|
|
|
remoteName = None
|
|
|
|
if d.remote:
|
2013-10-16 21:42:42 +00:00
|
|
|
remoteName = d.remote.remoteAlias or d.remote.name
|
2013-10-09 00:26:57 +00:00
|
|
|
if not d.remote or p.remote.name != remoteName:
|
2014-05-06 10:54:01 +00:00
|
|
|
remoteName = p.remote.name
|
|
|
|
e.setAttribute('remote', remoteName)
|
2009-03-05 18:32:38 +00:00
|
|
|
if peg_rev:
|
|
|
|
if self.IsMirror:
|
2012-09-29 03:21:57 +00:00
|
|
|
value = p.bare_git.rev_parse(p.revisionExpr + '^0')
|
2009-03-05 18:32:38 +00:00
|
|
|
else:
|
2012-09-29 03:21:57 +00:00
|
|
|
value = p.work_git.rev_parse(HEAD + '^0')
|
|
|
|
e.setAttribute('revision', value)
|
2015-07-10 21:54:54 +00:00
|
|
|
if peg_rev_upstream:
|
|
|
|
if p.upstream:
|
|
|
|
e.setAttribute('upstream', p.upstream)
|
|
|
|
elif value != p.revisionExpr:
|
|
|
|
# Only save the origin if the origin is not a sha1, and the default
|
|
|
|
# isn't our value
|
|
|
|
e.setAttribute('upstream', p.revisionExpr)
|
2014-05-06 10:54:01 +00:00
|
|
|
else:
|
|
|
|
revision = self.remotes[remoteName].revision or d.revisionExpr
|
|
|
|
if not revision or revision != p.revisionExpr:
|
|
|
|
e.setAttribute('revision', p.revisionExpr)
|
2014-07-24 10:57:08 +00:00
|
|
|
if p.upstream and p.upstream != p.revisionExpr:
|
|
|
|
e.setAttribute('upstream', p.upstream)
|
2009-03-05 18:32:38 +00:00
|
|
|
|
2015-07-24 10:50:06 +00:00
|
|
|
if p.dest_branch and p.dest_branch != d.destBranchExpr:
|
|
|
|
e.setAttribute('dest-branch', p.dest_branch)
|
|
|
|
|
2009-03-05 18:32:38 +00:00
|
|
|
for c in p.copyfiles:
|
|
|
|
ce = doc.createElement('copyfile')
|
|
|
|
ce.setAttribute('src', c.src)
|
|
|
|
ce.setAttribute('dest', c.dest)
|
|
|
|
e.appendChild(ce)
|
|
|
|
|
2014-04-21 22:10:59 +00:00
|
|
|
for l in p.linkfiles:
|
|
|
|
le = doc.createElement('linkfile')
|
|
|
|
le.setAttribute('src', l.src)
|
|
|
|
le.setAttribute('dest', l.dest)
|
|
|
|
e.appendChild(le)
|
|
|
|
|
2012-08-13 20:11:18 +00:00
|
|
|
default_groups = ['all', 'name:%s' % p.name, 'path:%s' % p.relpath]
|
2012-08-06 21:52:29 +00:00
|
|
|
egroups = [g for g in p.groups if g not in default_groups]
|
2012-04-16 17:36:08 +00:00
|
|
|
if egroups:
|
|
|
|
e.setAttribute('groups', ','.join(egroups))
|
2012-03-29 03:15:45 +00:00
|
|
|
|
2012-04-12 20:04:13 +00:00
|
|
|
for a in p.annotations:
|
|
|
|
if a.keep == "true":
|
|
|
|
ae = doc.createElement('annotation')
|
|
|
|
ae.setAttribute('name', a.name)
|
|
|
|
ae.setAttribute('value', a.value)
|
|
|
|
e.appendChild(ae)
|
|
|
|
|
2012-04-20 21:41:59 +00:00
|
|
|
if p.sync_c:
|
|
|
|
e.setAttribute('sync-c', 'true')
|
|
|
|
|
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 p.sync_s:
|
|
|
|
e.setAttribute('sync-s', 'true')
|
|
|
|
|
|
|
|
if p.subprojects:
|
2013-10-12 00:03:19 +00:00
|
|
|
subprojects = set(subp.name for subp in p.subprojects)
|
|
|
|
output_projects(p, e, list(sorted(subprojects)))
|
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
|
|
|
|
2013-10-12 00:03:19 +00:00
|
|
|
projects = set(p.name for p in self._paths.values() if not p.parent)
|
|
|
|
output_projects(None, root, list(sorted(projects)))
|
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
|
|
|
|
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
|
|
|
if self._repo_hooks_project:
|
|
|
|
root.appendChild(doc.createTextNode(''))
|
|
|
|
e = doc.createElement('repo-hooks')
|
|
|
|
e.setAttribute('in-project', self._repo_hooks_project.name)
|
|
|
|
e.setAttribute('enabled-list',
|
|
|
|
' '.join(self._repo_hooks_project.enabled_repo_hooks))
|
|
|
|
root.appendChild(e)
|
|
|
|
|
2009-03-05 18:32:38 +00:00
|
|
|
doc.writexml(fd, '', ' ', '\n', 'UTF-8')
|
|
|
|
|
2013-10-12 00:03:19 +00:00
|
|
|
@property
|
|
|
|
def paths(self):
|
|
|
|
self._Load()
|
|
|
|
return self._paths
|
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
@property
|
|
|
|
def projects(self):
|
|
|
|
self._Load()
|
2014-05-05 22:30:49 +00:00
|
|
|
return list(self._paths.values())
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
@property
|
|
|
|
def remotes(self):
|
|
|
|
self._Load()
|
|
|
|
return self._remotes
|
|
|
|
|
|
|
|
@property
|
|
|
|
def default(self):
|
|
|
|
self._Load()
|
|
|
|
return self._default
|
|
|
|
|
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
|
|
|
@property
|
|
|
|
def repo_hooks_project(self):
|
|
|
|
self._Load()
|
|
|
|
return self._repo_hooks_project
|
|
|
|
|
2010-11-01 22:08:06 +00:00
|
|
|
@property
|
|
|
|
def notice(self):
|
|
|
|
self._Load()
|
|
|
|
return self._notice
|
|
|
|
|
2010-04-06 17:40:01 +00:00
|
|
|
@property
|
|
|
|
def manifest_server(self):
|
|
|
|
self._Load()
|
2011-11-30 21:41:02 +00:00
|
|
|
return self._manifest_server
|
2010-04-06 17:40:01 +00:00
|
|
|
|
2008-11-04 15:37:10 +00:00
|
|
|
@property
|
|
|
|
def IsMirror(self):
|
|
|
|
return self.manifestProject.config.GetBoolean('repo.mirror')
|
|
|
|
|
2013-10-16 09:02:35 +00:00
|
|
|
@property
|
|
|
|
def IsArchive(self):
|
|
|
|
return self.manifestProject.config.GetBoolean('repo.archive')
|
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
def _Unload(self):
|
|
|
|
self._loaded = False
|
|
|
|
self._projects = {}
|
2013-10-12 00:03:19 +00:00
|
|
|
self._paths = {}
|
2008-10-21 14:00:00 +00:00
|
|
|
self._remotes = {}
|
|
|
|
self._default = None
|
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
|
|
|
self._repo_hooks_project = None
|
2010-11-01 22:08:06 +00:00
|
|
|
self._notice = None
|
2008-10-21 14:00:00 +00:00
|
|
|
self.branch = None
|
2010-04-06 17:40:01 +00:00
|
|
|
self._manifest_server = None
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
def _Load(self):
|
|
|
|
if not self._loaded:
|
2008-11-04 16:22:07 +00:00
|
|
|
m = self.manifestProject
|
|
|
|
b = m.GetBranch(m.CurrentBranch).merge
|
2009-06-25 23:47:30 +00:00
|
|
|
if b is not None and b.startswith(R_HEADS):
|
2008-11-04 16:22:07 +00:00
|
|
|
b = b[len(R_HEADS):]
|
|
|
|
self.branch = b
|
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
nodes = []
|
2012-06-08 03:05:35 +00:00
|
|
|
nodes.append(self._ParseManifestXml(self.manifestFile,
|
|
|
|
self.manifestProject.worktree))
|
2008-10-23 23:19:27 +00:00
|
|
|
|
|
|
|
local = os.path.join(self.repodir, LOCAL_MANIFEST_NAME)
|
|
|
|
if os.path.exists(local):
|
2013-02-14 07:28:44 +00:00
|
|
|
if not self.localManifestWarning:
|
|
|
|
self.localManifestWarning = True
|
|
|
|
print('warning: %s is deprecated; put local manifests in `%s` instead'
|
|
|
|
% (LOCAL_MANIFEST_NAME, os.path.join(self.repodir, LOCAL_MANIFESTS_DIR_NAME)),
|
|
|
|
file=sys.stderr)
|
2012-06-08 03:05:35 +00:00
|
|
|
nodes.append(self._ParseManifestXml(local, self.repodir))
|
2012-04-21 07:33:54 +00:00
|
|
|
|
2012-11-12 17:50:36 +00:00
|
|
|
local_dir = os.path.abspath(os.path.join(self.repodir, LOCAL_MANIFESTS_DIR_NAME))
|
|
|
|
try:
|
2012-11-13 19:53:24 +00:00
|
|
|
for local_file in sorted(os.listdir(local_dir)):
|
2012-11-12 17:50:36 +00:00
|
|
|
if local_file.endswith('.xml'):
|
2012-11-22 04:48:10 +00:00
|
|
|
local = os.path.join(local_dir, local_file)
|
|
|
|
nodes.append(self._ParseManifestXml(local, self.repodir))
|
2012-11-12 17:50:36 +00:00
|
|
|
except OSError:
|
|
|
|
pass
|
|
|
|
|
2013-01-11 20:35:53 +00:00
|
|
|
try:
|
|
|
|
self._ParseManifest(nodes)
|
|
|
|
except ManifestParseError as e:
|
|
|
|
# There was a problem parsing, unload ourselves in case they catch
|
|
|
|
# this error and try again later, we will show the correct error
|
|
|
|
self._Unload()
|
|
|
|
raise e
|
2008-10-23 23:19:27 +00:00
|
|
|
|
2008-11-04 15:37:10 +00:00
|
|
|
if self.IsMirror:
|
|
|
|
self._AddMetaProjectMirror(self.repoProject)
|
|
|
|
self._AddMetaProjectMirror(self.manifestProject)
|
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
self._loaded = True
|
|
|
|
|
2012-06-08 03:05:35 +00:00
|
|
|
def _ParseManifestXml(self, path, include_root):
|
2012-11-12 19:00:28 +00:00
|
|
|
try:
|
|
|
|
root = xml.dom.minidom.parse(path)
|
2012-11-12 17:50:36 +00:00
|
|
|
except (OSError, xml.parsers.expat.ExpatError) as e:
|
2012-11-12 19:00:28 +00:00
|
|
|
raise ManifestParseError("error parsing manifest %s: %s" % (path, e))
|
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
if not root or not root.childNodes:
|
2011-04-28 12:04:41 +00:00
|
|
|
raise ManifestParseError("no root node in %s" % (path,))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2012-08-26 17:25:59 +00:00
|
|
|
for manifest in root.childNodes:
|
|
|
|
if manifest.nodeName == 'manifest':
|
|
|
|
break
|
|
|
|
else:
|
2011-04-28 12:04:41 +00:00
|
|
|
raise ManifestParseError("no <manifest> in %s" % (path,))
|
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
nodes = []
|
2012-10-22 03:50:15 +00:00
|
|
|
for node in manifest.childNodes: # pylint:disable=W0631
|
2012-10-11 07:44:48 +00:00
|
|
|
# We only get here if manifest is initialised
|
2012-11-14 02:36:51 +00:00
|
|
|
if node.nodeName == 'include':
|
|
|
|
name = self._reqatt(node, 'name')
|
|
|
|
fp = os.path.join(include_root, name)
|
|
|
|
if not os.path.isfile(fp):
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError("include %s doesn't exist or isn't a file"
|
|
|
|
% (name,))
|
2012-11-14 02:36:51 +00:00
|
|
|
try:
|
|
|
|
nodes.extend(self._ParseManifestXml(fp, include_root))
|
|
|
|
# should isolate this to the exact exception, but that's
|
|
|
|
# tricky. actual parsing implementation may vary.
|
|
|
|
except (KeyboardInterrupt, RuntimeError, SystemExit):
|
|
|
|
raise
|
|
|
|
except Exception as e:
|
|
|
|
raise ManifestParseError(
|
|
|
|
"failed parsing included manifest %s: %s", (name, e))
|
|
|
|
else:
|
|
|
|
nodes.append(node)
|
2012-04-21 07:33:54 +00:00
|
|
|
return nodes
|
2011-04-28 12:04:41 +00:00
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
def _ParseManifest(self, node_list):
|
|
|
|
for node in itertools.chain(*node_list):
|
2008-10-21 14:00:00 +00:00
|
|
|
if node.nodeName == 'remote':
|
|
|
|
remote = self._ParseRemote(node)
|
2012-11-12 23:49:16 +00:00
|
|
|
if remote:
|
|
|
|
if remote.name in self._remotes:
|
|
|
|
if remote != self._remotes[remote.name]:
|
|
|
|
raise ManifestParseError(
|
|
|
|
'remote %s already exists with different attributes' %
|
|
|
|
(remote.name))
|
|
|
|
else:
|
|
|
|
self._remotes[remote.name] = remote
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
for node in itertools.chain(*node_list):
|
2008-10-21 14:00:00 +00:00
|
|
|
if node.nodeName == 'default':
|
2013-10-09 12:38:46 +00:00
|
|
|
new_default = self._ParseDefault(node)
|
|
|
|
if self._default is None:
|
|
|
|
self._default = new_default
|
|
|
|
elif new_default != self._default:
|
2013-10-15 01:48:40 +00:00
|
|
|
raise ManifestParseError('duplicate default in %s' %
|
|
|
|
(self.manifestFile))
|
2013-10-09 12:38:46 +00:00
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
if self._default is None:
|
|
|
|
self._default = _Default()
|
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
for node in itertools.chain(*node_list):
|
2010-11-01 22:08:06 +00:00
|
|
|
if node.nodeName == 'notice':
|
|
|
|
if self._notice is not None:
|
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
|
|
|
raise ManifestParseError(
|
|
|
|
'duplicate notice in %s' %
|
|
|
|
(self.manifestFile))
|
2010-11-01 22:08:06 +00:00
|
|
|
self._notice = self._ParseNotice(node)
|
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
for node in itertools.chain(*node_list):
|
2010-04-06 17:40:01 +00:00
|
|
|
if node.nodeName == 'manifest-server':
|
|
|
|
url = self._reqatt(node, 'url')
|
|
|
|
if self._manifest_server is not None:
|
2012-11-14 02:36:51 +00:00
|
|
|
raise ManifestParseError(
|
|
|
|
'duplicate manifest-server in %s' %
|
|
|
|
(self.manifestFile))
|
2010-04-06 17:40:01 +00:00
|
|
|
self._manifest_server = url
|
|
|
|
|
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
|
|
|
def recursively_add_projects(project):
|
2013-10-12 00:03:19 +00:00
|
|
|
projects = self._projects.setdefault(project.name, [])
|
|
|
|
if project.relpath is None:
|
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
|
|
|
raise ManifestParseError(
|
2013-10-12 00:03:19 +00:00
|
|
|
'missing path for %s in %s' %
|
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
|
|
|
(project.name, self.manifestFile))
|
2013-10-12 00:03:19 +00:00
|
|
|
if project.relpath in self._paths:
|
|
|
|
raise ManifestParseError(
|
|
|
|
'duplicate path %s in %s' %
|
|
|
|
(project.relpath, self.manifestFile))
|
|
|
|
self._paths[project.relpath] = project
|
|
|
|
projects.append(project)
|
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
|
|
|
for subproject in project.subprojects:
|
|
|
|
recursively_add_projects(subproject)
|
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
for node in itertools.chain(*node_list):
|
2008-10-21 14:00:00 +00:00
|
|
|
if node.nodeName == 'project':
|
|
|
|
project = self._ParseProject(node)
|
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
|
|
|
recursively_add_projects(project)
|
2014-06-12 21:57:29 +00:00
|
|
|
if node.nodeName == 'extend-project':
|
|
|
|
name = self._reqatt(node, 'name')
|
|
|
|
|
|
|
|
if name not in self._projects:
|
|
|
|
raise ManifestParseError('extend-project element specifies non-existent '
|
|
|
|
'project: %s' % name)
|
|
|
|
|
|
|
|
path = node.getAttribute('path')
|
|
|
|
groups = node.getAttribute('groups')
|
|
|
|
if groups:
|
|
|
|
groups = self._ParseGroups(groups)
|
|
|
|
|
|
|
|
for p in self._projects[name]:
|
|
|
|
if path and p.relpath != path:
|
|
|
|
continue
|
|
|
|
if groups:
|
|
|
|
p.groups.extend(groups)
|
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
|
|
|
if node.nodeName == 'repo-hooks':
|
|
|
|
# Get the name of the project and the (space-separated) list of enabled.
|
|
|
|
repo_hooks_project = self._reqatt(node, 'in-project')
|
|
|
|
enabled_repo_hooks = self._reqatt(node, 'enabled-list').split()
|
|
|
|
|
|
|
|
# Only one project can be the hooks project
|
|
|
|
if self._repo_hooks_project is not None:
|
|
|
|
raise ManifestParseError(
|
|
|
|
'duplicate repo-hooks in %s' %
|
|
|
|
(self.manifestFile))
|
|
|
|
|
|
|
|
# Store a reference to the Project.
|
|
|
|
try:
|
2013-10-12 00:03:19 +00:00
|
|
|
repo_hooks_projects = self._projects[repo_hooks_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
|
|
|
except KeyError:
|
|
|
|
raise ManifestParseError(
|
|
|
|
'project %s not found for repo-hooks' %
|
|
|
|
(repo_hooks_project))
|
|
|
|
|
2013-10-12 00:03:19 +00:00
|
|
|
if len(repo_hooks_projects) != 1:
|
|
|
|
raise ManifestParseError(
|
|
|
|
'internal error parsing repo-hooks in %s' %
|
|
|
|
(self.manifestFile))
|
|
|
|
self._repo_hooks_project = repo_hooks_projects[0]
|
|
|
|
|
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
|
|
|
# Store the enabled hooks in the Project object.
|
|
|
|
self._repo_hooks_project.enabled_repo_hooks = enabled_repo_hooks
|
2012-04-21 07:33:54 +00:00
|
|
|
if node.nodeName == 'remove-project':
|
|
|
|
name = self._reqatt(node, 'name')
|
2014-01-30 18:11:17 +00:00
|
|
|
|
|
|
|
if name not in self._projects:
|
2012-11-16 10:12:32 +00:00
|
|
|
raise ManifestParseError('remove-project element specifies non-existent '
|
|
|
|
'project: %s' % name)
|
2012-04-21 07:33:54 +00:00
|
|
|
|
2014-01-30 18:11:17 +00:00
|
|
|
for p in self._projects[name]:
|
|
|
|
del self._paths[p.relpath]
|
|
|
|
del self._projects[name]
|
|
|
|
|
2012-04-21 07:33:54 +00:00
|
|
|
# If the manifest removes the hooks project, treat it as if it deleted
|
|
|
|
# the repo-hooks element too.
|
|
|
|
if self._repo_hooks_project and (self._repo_hooks_project.name == name):
|
|
|
|
self._repo_hooks_project = None
|
|
|
|
|
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
|
|
|
|
2008-11-04 15:37:10 +00:00
|
|
|
def _AddMetaProjectMirror(self, m):
|
|
|
|
name = None
|
|
|
|
m_url = m.GetRemote(m.remote.name).url
|
|
|
|
if m_url.endswith('/.git'):
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError('refusing to mirror %s' % m_url)
|
2008-11-04 15:37:10 +00:00
|
|
|
|
|
|
|
if self._default and self._default.remote:
|
2011-10-20 17:45:47 +00:00
|
|
|
url = self._default.remote.resolvedFetchUrl
|
2008-11-04 15:37:10 +00:00
|
|
|
if not url.endswith('/'):
|
|
|
|
url += '/'
|
|
|
|
if m_url.startswith(url):
|
|
|
|
remote = self._default.remote
|
|
|
|
name = m_url[len(url):]
|
|
|
|
|
|
|
|
if name is None:
|
|
|
|
s = m_url.rindex('/') + 1
|
2011-09-26 23:34:01 +00:00
|
|
|
manifestUrl = self.manifestProject.config.GetString('remote.origin.url')
|
2012-08-02 18:46:22 +00:00
|
|
|
remote = _XmlRemote('origin', fetch=m_url[:s], manifestUrl=manifestUrl)
|
2008-11-04 15:37:10 +00:00
|
|
|
name = m_url[s:]
|
|
|
|
|
|
|
|
if name.endswith('.git'):
|
|
|
|
name = name[:-4]
|
|
|
|
|
|
|
|
if name not in self._projects:
|
|
|
|
m.PreSync()
|
|
|
|
gitdir = os.path.join(self.topdir, '%s.git' % name)
|
|
|
|
project = Project(manifest = self,
|
|
|
|
name = name,
|
2009-05-19 21:58:02 +00:00
|
|
|
remote = remote.ToRemoteSpec(name),
|
2008-11-04 15:37:10 +00:00
|
|
|
gitdir = gitdir,
|
2013-10-12 00:03:19 +00:00
|
|
|
objdir = gitdir,
|
2008-11-04 15:37:10 +00:00
|
|
|
worktree = None,
|
2014-02-17 04:07:32 +00:00
|
|
|
relpath = name or None,
|
2009-05-30 01:38:17 +00:00
|
|
|
revisionExpr = m.revisionExpr,
|
|
|
|
revisionId = None)
|
2013-10-12 00:03:19 +00:00
|
|
|
self._projects[project.name] = [project]
|
2014-02-17 04:07:32 +00:00
|
|
|
self._paths[project.relpath] = project
|
2008-11-04 15:37:10 +00:00
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
def _ParseRemote(self, node):
|
|
|
|
"""
|
|
|
|
reads a <remote> element from the manifest file
|
|
|
|
"""
|
|
|
|
name = self._reqatt(node, 'name')
|
2012-07-02 14:32:50 +00:00
|
|
|
alias = node.getAttribute('alias')
|
|
|
|
if alias == '':
|
|
|
|
alias = None
|
2008-10-21 14:00:00 +00:00
|
|
|
fetch = self._reqatt(node, 'fetch')
|
|
|
|
review = node.getAttribute('review')
|
2008-11-06 18:25:35 +00:00
|
|
|
if review == '':
|
|
|
|
review = None
|
2014-05-06 10:54:01 +00:00
|
|
|
revision = node.getAttribute('revision')
|
|
|
|
if revision == '':
|
|
|
|
revision = None
|
2011-09-26 23:34:01 +00:00
|
|
|
manifestUrl = self.manifestProject.config.GetString('remote.origin.url')
|
2015-03-17 18:29:58 +00:00
|
|
|
return _XmlRemote(name, alias, fetch, manifestUrl, review, revision)
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
def _ParseDefault(self, node):
|
|
|
|
"""
|
|
|
|
reads a <default> element from the manifest file
|
|
|
|
"""
|
|
|
|
d = _Default()
|
|
|
|
d.remote = self._get_remote(node)
|
2009-05-30 01:38:17 +00:00
|
|
|
d.revisionExpr = node.getAttribute('revision')
|
|
|
|
if d.revisionExpr == '':
|
|
|
|
d.revisionExpr = None
|
2012-04-20 21:41:59 +00:00
|
|
|
|
2013-05-06 17:36:24 +00:00
|
|
|
d.destBranchExpr = node.getAttribute('dest-branch') or None
|
|
|
|
|
2011-09-23 00:44:31 +00:00
|
|
|
sync_j = node.getAttribute('sync-j')
|
|
|
|
if sync_j == '' or sync_j is None:
|
|
|
|
d.sync_j = 1
|
|
|
|
else:
|
|
|
|
d.sync_j = int(sync_j)
|
2012-04-20 21:41:59 +00:00
|
|
|
|
|
|
|
sync_c = node.getAttribute('sync-c')
|
|
|
|
if not sync_c:
|
|
|
|
d.sync_c = False
|
|
|
|
else:
|
|
|
|
d.sync_c = sync_c.lower() in ("yes", "true", "1")
|
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
|
|
|
|
|
|
|
sync_s = node.getAttribute('sync-s')
|
|
|
|
if not sync_s:
|
|
|
|
d.sync_s = False
|
|
|
|
else:
|
|
|
|
d.sync_s = sync_s.lower() in ("yes", "true", "1")
|
2008-10-21 14:00:00 +00:00
|
|
|
return d
|
|
|
|
|
2010-11-01 22:08:06 +00:00
|
|
|
def _ParseNotice(self, node):
|
|
|
|
"""
|
|
|
|
reads a <notice> element from the manifest file
|
|
|
|
|
|
|
|
The <notice> element is distinct from other tags in the XML in that the
|
|
|
|
data is conveyed between the start and end tag (it's not an empty-element
|
|
|
|
tag).
|
|
|
|
|
|
|
|
The white space (carriage returns, indentation) for the notice element is
|
|
|
|
relevant and is parsed in a way that is based on how python docstrings work.
|
|
|
|
In fact, the code is remarkably similar to here:
|
|
|
|
http://www.python.org/dev/peps/pep-0257/
|
|
|
|
"""
|
|
|
|
# Get the data out of the node...
|
|
|
|
notice = node.childNodes[0].data
|
|
|
|
|
|
|
|
# Figure out minimum indentation, skipping the first line (the same line
|
|
|
|
# as the <notice> tag)...
|
2013-03-01 13:44:38 +00:00
|
|
|
minIndent = sys.maxsize
|
2010-11-01 22:08:06 +00:00
|
|
|
lines = notice.splitlines()
|
|
|
|
for line in lines[1:]:
|
|
|
|
lstrippedLine = line.lstrip()
|
|
|
|
if lstrippedLine:
|
|
|
|
indent = len(line) - len(lstrippedLine)
|
|
|
|
minIndent = min(indent, minIndent)
|
|
|
|
|
|
|
|
# Strip leading / trailing blank lines and also indentation.
|
|
|
|
cleanLines = [lines[0].strip()]
|
|
|
|
for line in lines[1:]:
|
|
|
|
cleanLines.append(line[minIndent:].rstrip())
|
|
|
|
|
|
|
|
# Clear completely blank lines from front and back...
|
|
|
|
while cleanLines and not cleanLines[0]:
|
|
|
|
del cleanLines[0]
|
|
|
|
while cleanLines and not cleanLines[-1]:
|
|
|
|
del cleanLines[-1]
|
|
|
|
|
|
|
|
return '\n'.join(cleanLines)
|
|
|
|
|
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
|
|
|
def _JoinName(self, parent_name, name):
|
|
|
|
return os.path.join(parent_name, name)
|
|
|
|
|
|
|
|
def _UnjoinName(self, parent_name, name):
|
|
|
|
return os.path.relpath(name, parent_name)
|
|
|
|
|
|
|
|
def _ParseProject(self, node, parent = None):
|
2008-10-21 14:00:00 +00:00
|
|
|
"""
|
|
|
|
reads a <project> element from the manifest file
|
2010-04-06 17:40:01 +00:00
|
|
|
"""
|
2008-10-21 14:00:00 +00:00
|
|
|
name = self._reqatt(node, 'name')
|
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 parent:
|
|
|
|
name = self._JoinName(parent.name, name)
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
remote = self._get_remote(node)
|
|
|
|
if remote is None:
|
|
|
|
remote = self._default.remote
|
|
|
|
if remote is None:
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError("no remote for project %s within %s" %
|
|
|
|
(name, self.manifestFile))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2014-05-06 10:54:01 +00:00
|
|
|
revisionExpr = node.getAttribute('revision') or remote.revision
|
2009-05-30 01:38:17 +00:00
|
|
|
if not revisionExpr:
|
|
|
|
revisionExpr = self._default.revisionExpr
|
|
|
|
if not revisionExpr:
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError("no revision for project %s within %s" %
|
|
|
|
(name, self.manifestFile))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
path = node.getAttribute('path')
|
|
|
|
if not path:
|
|
|
|
path = name
|
|
|
|
if path.startswith('/'):
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError("project %s path cannot be absolute in %s" %
|
|
|
|
(name, self.manifestFile))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2012-02-28 19:53:24 +00:00
|
|
|
rebase = node.getAttribute('rebase')
|
|
|
|
if not rebase:
|
|
|
|
rebase = True
|
|
|
|
else:
|
|
|
|
rebase = rebase.lower() in ("yes", "true", "1")
|
|
|
|
|
2012-04-20 21:41:59 +00:00
|
|
|
sync_c = node.getAttribute('sync-c')
|
|
|
|
if not sync_c:
|
|
|
|
sync_c = False
|
|
|
|
else:
|
|
|
|
sync_c = sync_c.lower() in ("yes", "true", "1")
|
|
|
|
|
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
|
|
|
sync_s = node.getAttribute('sync-s')
|
|
|
|
if not sync_s:
|
|
|
|
sync_s = self._default.sync_s
|
|
|
|
else:
|
|
|
|
sync_s = sync_s.lower() in ("yes", "true", "1")
|
|
|
|
|
2012-11-27 13:25:30 +00:00
|
|
|
clone_depth = node.getAttribute('clone-depth')
|
|
|
|
if clone_depth:
|
|
|
|
try:
|
|
|
|
clone_depth = int(clone_depth)
|
|
|
|
if clone_depth <= 0:
|
|
|
|
raise ValueError()
|
|
|
|
except ValueError:
|
|
|
|
raise ManifestParseError('invalid clone-depth %s in %s' %
|
|
|
|
(clone_depth, self.manifestFile))
|
|
|
|
|
2013-05-06 17:36:24 +00:00
|
|
|
dest_branch = node.getAttribute('dest-branch') or self._default.destBranchExpr
|
|
|
|
|
2012-09-29 03:21:57 +00:00
|
|
|
upstream = node.getAttribute('upstream')
|
|
|
|
|
2012-04-16 17:36:08 +00:00
|
|
|
groups = ''
|
|
|
|
if node.hasAttribute('groups'):
|
|
|
|
groups = node.getAttribute('groups')
|
2014-06-12 21:57:29 +00:00
|
|
|
groups = self._ParseGroups(groups)
|
2012-06-15 09:24:20 +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
|
|
|
if parent is None:
|
2013-10-12 00:03:19 +00:00
|
|
|
relpath, worktree, gitdir, objdir = self.GetProjectPaths(name, path)
|
2012-10-26 19:18:00 +00:00
|
|
|
else:
|
2013-10-12 00:03:19 +00:00
|
|
|
relpath, worktree, gitdir, objdir = \
|
|
|
|
self.GetSubprojectPaths(parent, name, path)
|
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
|
|
|
|
|
|
|
default_groups = ['all', 'name:%s' % name, 'path:%s' % relpath]
|
|
|
|
groups.extend(set(default_groups).difference(groups))
|
2012-10-26 19:18:00 +00:00
|
|
|
|
2013-02-28 01:34:14 +00:00
|
|
|
if self.IsMirror and node.hasAttribute('force-path'):
|
|
|
|
if node.getAttribute('force-path').lower() in ("yes", "true", "1"):
|
|
|
|
gitdir = os.path.join(self.topdir, '%s.git' % path)
|
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
project = Project(manifest = self,
|
|
|
|
name = name,
|
2009-05-19 21:58:02 +00:00
|
|
|
remote = remote.ToRemoteSpec(name),
|
2008-10-21 14:00:00 +00:00
|
|
|
gitdir = gitdir,
|
2013-10-12 00:03:19 +00:00
|
|
|
objdir = objdir,
|
2008-10-21 14:00:00 +00:00
|
|
|
worktree = worktree,
|
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
|
|
|
relpath = relpath,
|
2009-05-30 01:38:17 +00:00
|
|
|
revisionExpr = revisionExpr,
|
2012-02-28 19:53:24 +00:00
|
|
|
revisionId = None,
|
2012-03-29 03:15:45 +00:00
|
|
|
rebase = rebase,
|
2012-04-20 21:41:59 +00:00
|
|
|
groups = groups,
|
2012-09-29 03:21:57 +00:00
|
|
|
sync_c = sync_c,
|
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
|
|
|
sync_s = sync_s,
|
2012-11-27 13:25:30 +00:00
|
|
|
clone_depth = clone_depth,
|
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
|
|
|
upstream = upstream,
|
2013-05-06 17:36:24 +00:00
|
|
|
parent = parent,
|
|
|
|
dest_branch = dest_branch)
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
for n in node.childNodes:
|
2009-05-19 20:00:29 +00:00
|
|
|
if n.nodeName == 'copyfile':
|
2008-10-21 14:00:00 +00:00
|
|
|
self._ParseCopyFile(project, n)
|
2014-04-21 22:10:59 +00:00
|
|
|
if n.nodeName == 'linkfile':
|
|
|
|
self._ParseLinkFile(project, n)
|
2012-04-12 20:04:13 +00:00
|
|
|
if n.nodeName == 'annotation':
|
|
|
|
self._ParseAnnotation(project, n)
|
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 n.nodeName == 'project':
|
|
|
|
project.subprojects.append(self._ParseProject(n, parent = project))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
|
|
|
return project
|
|
|
|
|
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
|
|
|
def GetProjectPaths(self, name, path):
|
|
|
|
relpath = path
|
|
|
|
if self.IsMirror:
|
|
|
|
worktree = None
|
|
|
|
gitdir = os.path.join(self.topdir, '%s.git' % name)
|
2013-10-12 00:03:19 +00:00
|
|
|
objdir = gitdir
|
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
|
|
|
else:
|
|
|
|
worktree = os.path.join(self.topdir, path).replace('\\', '/')
|
|
|
|
gitdir = os.path.join(self.repodir, 'projects', '%s.git' % path)
|
2013-10-12 00:03:19 +00:00
|
|
|
objdir = os.path.join(self.repodir, 'project-objects', '%s.git' % name)
|
|
|
|
return relpath, worktree, gitdir, objdir
|
|
|
|
|
|
|
|
def GetProjectsWithName(self, name):
|
|
|
|
return self._projects.get(name, [])
|
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
|
|
|
|
|
|
|
def GetSubprojectName(self, parent, submodule_path):
|
|
|
|
return os.path.join(parent.name, submodule_path)
|
|
|
|
|
|
|
|
def _JoinRelpath(self, parent_relpath, relpath):
|
|
|
|
return os.path.join(parent_relpath, relpath)
|
|
|
|
|
|
|
|
def _UnjoinRelpath(self, parent_relpath, relpath):
|
|
|
|
return os.path.relpath(relpath, parent_relpath)
|
|
|
|
|
2013-10-12 00:03:19 +00:00
|
|
|
def GetSubprojectPaths(self, parent, name, path):
|
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
|
|
|
relpath = self._JoinRelpath(parent.relpath, path)
|
|
|
|
gitdir = os.path.join(parent.gitdir, 'subprojects', '%s.git' % path)
|
2013-10-12 00:03:19 +00:00
|
|
|
objdir = os.path.join(parent.gitdir, 'subproject-objects', '%s.git' % name)
|
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 self.IsMirror:
|
|
|
|
worktree = None
|
|
|
|
else:
|
|
|
|
worktree = os.path.join(parent.worktree, path).replace('\\', '/')
|
2013-10-12 00:03:19 +00:00
|
|
|
return relpath, worktree, gitdir, objdir
|
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
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
def _ParseCopyFile(self, project, node):
|
|
|
|
src = self._reqatt(node, 'src')
|
|
|
|
dest = self._reqatt(node, 'dest')
|
2008-11-04 15:37:10 +00:00
|
|
|
if not self.IsMirror:
|
|
|
|
# src is project relative;
|
|
|
|
# dest is relative to the top of the tree
|
2009-03-05 18:32:38 +00:00
|
|
|
project.AddCopyFile(src, dest, os.path.join(self.topdir, dest))
|
2008-10-21 14:00:00 +00:00
|
|
|
|
2014-04-21 22:10:59 +00:00
|
|
|
def _ParseLinkFile(self, project, node):
|
|
|
|
src = self._reqatt(node, 'src')
|
|
|
|
dest = self._reqatt(node, 'dest')
|
|
|
|
if not self.IsMirror:
|
|
|
|
# src is project relative;
|
|
|
|
# dest is relative to the top of the tree
|
|
|
|
project.AddLinkFile(src, dest, os.path.join(self.topdir, dest))
|
|
|
|
|
2012-04-12 20:04:13 +00:00
|
|
|
def _ParseAnnotation(self, project, node):
|
|
|
|
name = self._reqatt(node, 'name')
|
|
|
|
value = self._reqatt(node, 'value')
|
|
|
|
try:
|
|
|
|
keep = self._reqatt(node, 'keep').lower()
|
|
|
|
except ManifestParseError:
|
|
|
|
keep = "true"
|
|
|
|
if keep != "true" and keep != "false":
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError('optional "keep" attribute must be '
|
|
|
|
'"true" or "false"')
|
2012-04-12 20:04:13 +00:00
|
|
|
project.AddAnnotation(name, value, keep)
|
|
|
|
|
2008-10-21 14:00:00 +00:00
|
|
|
def _get_remote(self, node):
|
|
|
|
name = node.getAttribute('remote')
|
|
|
|
if not name:
|
|
|
|
return None
|
|
|
|
|
|
|
|
v = self._remotes.get(name)
|
|
|
|
if not v:
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError("remote %s not defined in %s" %
|
|
|
|
(name, self.manifestFile))
|
2008-10-21 14:00:00 +00:00
|
|
|
return v
|
|
|
|
|
|
|
|
def _reqatt(self, node, attname):
|
|
|
|
"""
|
|
|
|
reads a required attribute from the node.
|
|
|
|
"""
|
|
|
|
v = node.getAttribute(attname)
|
|
|
|
if not v:
|
2013-03-01 13:44:38 +00:00
|
|
|
raise ManifestParseError("no %s in <%s> within %s" %
|
|
|
|
(attname, node.nodeName, self.manifestFile))
|
2008-10-21 14:00:00 +00:00
|
|
|
return v
|
2014-01-09 15:21:37 +00:00
|
|
|
|
|
|
|
def projectsDiff(self, manifest):
|
|
|
|
"""return the projects differences between two manifests.
|
|
|
|
|
|
|
|
The diff will be from self to given manifest.
|
|
|
|
|
|
|
|
"""
|
|
|
|
fromProjects = self.paths
|
|
|
|
toProjects = manifest.paths
|
|
|
|
|
2014-05-06 08:19:39 +00:00
|
|
|
fromKeys = sorted(fromProjects.keys())
|
|
|
|
toKeys = sorted(toProjects.keys())
|
2014-01-09 15:21:37 +00:00
|
|
|
|
|
|
|
diff = {'added': [], 'removed': [], 'changed': [], 'unreachable': []}
|
|
|
|
|
|
|
|
for proj in fromKeys:
|
|
|
|
if not proj in toKeys:
|
|
|
|
diff['removed'].append(fromProjects[proj])
|
|
|
|
else:
|
|
|
|
fromProj = fromProjects[proj]
|
|
|
|
toProj = toProjects[proj]
|
|
|
|
try:
|
|
|
|
fromRevId = fromProj.GetCommitRevisionId()
|
|
|
|
toRevId = toProj.GetCommitRevisionId()
|
|
|
|
except ManifestInvalidRevisionError:
|
|
|
|
diff['unreachable'].append((fromProj, toProj))
|
|
|
|
else:
|
|
|
|
if fromRevId != toRevId:
|
|
|
|
diff['changed'].append((fromProj, toProj))
|
|
|
|
toKeys.remove(proj)
|
|
|
|
|
|
|
|
for proj in toKeys:
|
|
|
|
diff['added'].append(toProjects[proj])
|
|
|
|
|
|
|
|
return diff
|