summaryrefslogtreecommitdiffstats
path: root/manifest_xml.py
Commit message (Collapse)AuthorAgeFilesLines
...
* Add support for multiple local manifestsDavid Pursehouse2012-11-131-1/+13
| | | | | | | | | Add support for multiple local manifests stored in the local_manifests folder under the .repo home directory. Local manifests will be processed in addition to local_manifest.xml. Change-Id: Ia0569cea7e9ae0fe3208a8ffef5d9679e14db03b
* Handle XML errors when parsing the manifestDavid Pursehouse2012-11-131-1/+5
| | | | | | | Catch ExpatError and exit gracefully with an error message, rather than exiting with a python traceback. Change-Id: Ifd0a7762aab4e8de63dab8a66117170a05586866
* Even more coding style cleanupDavid Pursehouse2012-10-301-1/+1
| | | | | | | | | | | Fixing some more pylint warnings: W1401: Anomalous backslash in string W0623: Redefining name 'name' from outer scope W0702: No exception type(s) specified E0102: name: function already defined line n Change-Id: I5afcdb4771ce210390a79981937806e30900a93c
* Revert "Represent git-submodule as nested projects"v1.11.1Shawn O. Pearce2012-10-261-82/+26
| | | | | | | | | | | This reverts commit 69998b0c6ff724bf620480140ccce648fec7d6a9. Broke Android's non-gitmodule use case. Conflicts: project.py subcmds/sync.py Change-Id: I68ceeb63d8ee3b939f85a64736bdc81dfa352aed
* Merge "Use modern Python exception syntax"Conley Owens2012-10-251-1/+1
|\
| * Use modern Python exception syntaxSarah Owens2012-10-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | "except Exception as e" instead of "except Exception, e" This is part of a transition to supporting Python 3. Python >= 2.6 support "as" syntax. Note: this removes Python 2.5 support. Change-Id: I309599f3981bba2b46111c43102bee38ff132803
* | Add pylint configuration and instructionsDavid Pursehouse2012-10-241-1/+1
| | | | | | | | | | | | | | | | | | | | pylint configuration file (.pylintrc) is added, and submission instructions are updated to include pylint usage steps. Deprecated pylint suppression (`disable-msg`) is updated in a few modules to make it work properly with the latest version (0.26). Change-Id: I4ec2ef318e23557a374ecdbf40fe12645766830c
* | Represent git-submodule as nested projectsChe-Liang Chiou2012-10-231-26/+82
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* More coding style cleanupDavid Pursehouse2012-10-221-1/+2
| | | | | | | | | | | | | | | | Fixing more issues found with pylint. Some that were supposed to have been fixed in the previous sweep (Ie0db839e) but were missed: C0321: More than one statement on a single line W0622: Redefining built-in 'name' And some more: W0631: Using possibly undefined loop variable 'name' W0223: Method 'name' is abstract in class 'name' but is not overridden W0231: __init__ method from base class 'name' is not called Change-Id: Ie119183708609d6279e973057a385fde864230c3
* Coding style cleanupDavid Pursehouse2012-10-091-2/+1
| | | | | | | | | | | | | | | Fix the following issues reported by pylint: C0321: More than one statement on a single line W0622: Redefining built-in 'name' W0612: Unused variable 'name' W0613: Unused argument 'name' W0102: Dangerous default value 'value' as argument W0105: String statement has no effect Also fixed a few cases of inconsistent indentation. Change-Id: Ie0db839e7c57d576cff12d8c055fe87030d00744
* Merge "manifest: record the original revision when in -r mode."Conley Owens2012-10-031-6/+13
|\
| * manifest: record the original revision when in -r mode.Brian Harring2012-09-281-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently when doing a sync against a revision locked manifest, sync has no option but to fall back to sync'ing the entire refs space; it doesn't know which ref to ask for that contains the sha1 it wants. This sucks if we're in -c mode; thus when we generate a revision locked manifest, record the originating branch- and try syncing that branch first. If the sha1 is found within that branch, this saves us having to pull down the rest of the repo- a potentially heavy saving. If that branch doesn't have the desired sha1, we fallback to sync'ing everything. Change-Id: I99a5e44fa1d792dfcada76956a2363187df94cf1
* | Fix incorrect default_groups when parsing projects from XML manifestDavid Holmer2012-09-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Change Details: * Switch first default group to 'all' instead of 'default' Change Benefits: * More consistent with default_groups in the counterpart Save() function * Fixes bug where command 'repo manifest' added an extra 'default' group to every output project element groups attribute. This bug was particularly confusing for projects which had 'groups="notdefault"' as they were output as 'groups="notdefault,default"' by 'repo manifest' Change-Id: I5611c027a982d3394899466248b971910bec8c6b
* | Clean up importsDavid Pursehouse2012-09-181-1/+2
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | manifest_xml: import `HEAD` and `R_HEADS` from correct module version: import `HEAD` from correct module `HEAD` and `R_HEADS` should be imported from the git_refs module, where they are originally defined, rather than from the project module. repo: remove unused import of readline cherry_pick: import standard modules on separate lines smartsync: import subcmd modules explicitly from subcmd Use: `import re import sys` and `from subcmds.sync import Sync` Instead of: `import sys, re` and `from sync import Sync` Change-Id: Ie10dd6832710939634c4f5c86b9ba5a9cd6fc92e
* Fix ManifestParseError when first child node is commentv1.10.4Jooncheol Park2012-09-071-3/+5
| | | | | | | | | | | | If the first line of manifest.xml is a XML comment, root.childNodes[0] is not a 'manifest' element node. The python minidom module will makes a 'Comment' node as root.childNodes[0]. Since the original code only checks whether the first child node is 'manifest', it couldn't do any command including 'sync' due to the 'ManifestParseError' exception. This patch could allow the comments between '<?xml ...?>' and '<manifest>' in the manifest.xml file. Change-Id: I0b81dea4f806965eca90f704c8aa7df49c579402
* Allow projects to be specified as notdefaultConley Owens2012-09-051-2/+2
| | | | | | | | | | | | Instead of every group being in the group "default", every project is now in the group "all". A group that should not be downloaded by default may be added to the group "notdefault". This allows all group names to be positive (instead of removing groups directly in the manifest with -default) and offers a clear way of selecting every project (--groups all). Change-Id: I99cd70309adb1f8460db3bbc6eff46bdcd22256f
* Remove unused importsDavid Pursehouse2012-08-231-1/+1
| | | | | | There are several imports that are not used. Remove them. Change-Id: I2ac3be66827bd68d3faedcef7d6bbf30ea01d3f2
* Omit all default groups when generating a manifestDmitry Fink2012-08-071-1/+2
| | | | | | | | One of the recent changes introduced implicit path:xxx and name:xxx groups to every project, however they are not being stripped when generating a manifest using "repo manifest" command resulting in clutter Change-Id: Iec8610ba794b2fe4a6cdf0f59ca561595b66f9b5
* Fix mirror modev1.10.2Shawn O. Pearce2012-08-021-1/+1
| | | | Change-Id: Ica0e8392562a7ae5aad7e45441c1540e5e2b0238
* Add remote alias support in manifestYestin Sun2012-07-311-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `alias` is an optional attribute in element `remote`. It can be used to override attibute `name` to be set as the remote name in each project's .git/config. Its value can be duplicated while attribute `name` has to be unique across the manifest file. This helps each project to be able to have same remote name which actually points to different remote url. It eases some automation scripts to be able to checkout/push to same remote name but actually different remote url, like: repo forall -c "git checkout -b work same_remote/work" repo forall -c "git push same_remote work:work" for example: The manifest with 'alias' will look like: <?xml version='1.0' encoding='UTF-8'?> <manifest> <remote alias="same_alias" fetch="git://git.external1.org/" name="ext1" review="http://review.external1.org"/> <remote alias="same_alias" fetch="git://git.external2.org/" name="ext2" review="http://review.external2.org"/> <remote alias="same_alias" fetch="ssh://git.internal.com:29418" name="int" review="http://review.internal.com"/> <default remote="int" revision="int-branch" sync-j="2"/> <project name="path/to/project1" path="project1" remote="ext1"/> <project name="path/to/project2" path="project2" remote="ext2"/> <project name="path/to/project3" path="project3"/> ... </manifest> In each project, use command "git remote -v" project1: same_alias git://git.external1.org/project1 (fetch) same_alias git://git.external1.org/project1 (push) project2: same_alias git://git.external2.org/project2 (fetch) same_alias git://git.external2.org/project2 (push) project3: same_alias ssh://git.internal.com:29418/project3 (fetch) same_alias ssh://git.internal.com:29418/project3 (push) Change-Id: I2c48263097ff107f0c978f3e83966ae71d06cb90
* Inject the project name into each projects groups.Brian Harring2012-07-311-2/+3
| | | | | | | | | | | | | | For CrOS, we have scenarios were people checkout a smaller version of our manifest via groups, and enable individual repositories as needed for their work. Previously this was via local_manifest manipulation, which breaks via manifest-groups would require a remove-project tag. Via injecting the projects name into the projects groups, this allows us to instead manipulate the configured groups allowing the user to turn on/off projects as necessary. Change-Id: I07b7918e16cc9dc28eb47e19a46a04dc4fd0be74
* Restore include support.Brian Harring2012-06-071-5/+6
| | | | | | | | | | | | | | | | Calculation of where the include file lives was broken by 23acdd3f14 since it resulted in looking for the first include in .repo, rather than .repo/manifests. While people can work around it via setting their includes to manifests/<include-target>, that breaks down since each layer of includes would then have to be relative. As such, restore the behaviour back to 2644874d; manifests includes are calculated relative to the manifest root (ie, .repo/manifests); local manifests includes are calculated relative to .repo/ . Change-Id: I74c19ba614c41d2f08cd3e9fd094f3c510e3bfd1
* Parse manifest and local_manifest togetherColin Cross2012-05-241-41/+33
| | | | | | | | Combine manifest and local_manifest into a single list of elements before parsing. This will allow elements in the local_manifest to affect elements in the main manifest. Change-Id: I4d34c9260b299a76be2960b07c0c3fe1af35f33c
* ManifestXml: add include supportBrian Harring2012-05-241-8/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Having the ability to include other manifests is a very practical feature to ease the managment of manifest. It allows to divide a manifest into separate files, and create different environment depending on what we want to release You can have unlimited recursion of include, the manifest configs will simply be concatenated as if it was in a single file. command "repo manifest" will create a single manifest, and not recreate the manifest hierarchy for example: Our developement manifest will look like: <?xml version='1.0' encoding='UTF-8'?> <manifest> <default revision="platform/android/main" remote="intel"/> <include name="server.xml"/> <!-- The Server configuration --> <include name="aosp.xml" /> <!-- All the AOSP projects --> <include name="bsp.xml" /> <!-- The BSP projects that we release in source form --> <include name="bsp-priv.xml" /> <!-- The source of the BSP projects we release in binary form --> </manifest> Our release manifest will look like: <?xml version='1.0' encoding='UTF-8'?> <manifest> <default revision="platform/android/release-ext" remote="intel"/> <include name="server.xml"/> <!-- The Server configuration --> <include name="aosp.xml" /> <!-- All the AOSP projects --> <include name="bsp.xml" /> <!-- The BSP projects that we release in source form --> <include name="bsp-ext.xml" /> <!-- The PREBUILT version of the BSP projects we release in binary form --> </manifest> And it is also easy to create and maintain feature branch with a manifest that looks like: <?xml version='1.0' encoding='UTF-8'?> <manifest> <default revision="feature_branch_foobar" remote="intel"/> <include name="server.xml"/> <!-- The Server configuration --> <include name="aosp.xml" /> <!-- All the AOSP projects --> <include name="bsp.xml" /> <!-- The BSP projects that we release in source form --> <include name="bsp-priv.xml" /> <!-- The source of the BSP projects we release in binary form --> </manifest> Signed-off-by: Brian Harring <brian.harring@intel.com> Signed-off-by: Pierre Tardy <pierre.tardy@intel.com> Change-Id: I833a30d303039e485888768e6b81561b7665e89d
* Add sync-c option to manifestAnatol Pomazau2012-04-231-1/+22
| | | | | | | | | | | | | | | | | There are use-cases when fetching all branch is impractical and we really need to fetch only one branch/tag. e.g. there is a large project with binaries and every update of a binary file is put to a separate branch. The whole project history might be too large to allow users fetch it. Add 'sync-c' option to 'project' and 'default' tags to make it possible to configure 'sync-c' behavior at per-project and per-manifest level. Note that currently there is no possibility to revert boolean flag from command line. If 'sync-c' is set in manifest then you cannot make full fetch by providing a repo tool argument. Change-Id: Ie36fe5737304930493740370239403986590f593
* Treat groups= as defaultColin Cross2012-04-231-1/+1
| | | | | | | | | Previous incarnations of groups support left "groups=" in the repo .config, which is now treated as "delete all the projects". Treat empty groups configuration the same as no groups configuration. Change-Id: I57dab8dac55bdbf4cc181e2748cd2e4e510764f5
* Refine groups functionalityConley Owens2012-04-231-9/+12
| | | | | | | | | | | | | | | Every project is in group "default". "-default" does not remove it from this project. All group names specified in the manifest are positive names as opposed to a mix of negative and positive. Specified groups are resolved in order. If init is supplied with --groups="group1,-group2", the following describes the project selection when syncing: * all projects in "group1" will be added, and * all projects in "group2" will be removed. Change-Id: I1df3dcdb64bbd4cd80d675f9b2d3becbf721f661
* Add project annotation handling to repoJames W. Mills2012-04-231-0/+20
| | | | | | | | | | | | | | Allow the optional addition of "annotation" nodes nested under projects. Each annotation node must have "name" and "value" attributes. These name/value pairs will be exported into the environment during any forall command, prefixed with "REPO__" In addition, an optional "keep" attribute with case insensitive "true" or "false" values can be included to determine whether the annotation will be exported with 'repo manifest' Change-Id: Icd7540afaae02c958f769ce3d25661aa721a9de8 Signed-off-by: James W. Mills <jameswmills@gmail.com>
* Add manifest groupsv1.8.2Colin Cross2012-04-131-1/+21
| | | | | | | | | | | | | | | | | Allows specifying a list of groups with a -g argument to repo init. The groups act on a group= attribute specified on projects in the manifest. All projects are implicitly labelled with "default" unless they are explicitly labelled "-default". Prefixing a group with "-" removes matching projects from the list of projects to sync. If any non-inverted manifest groups are specified, the default label is ignored. Change-Id: I3a0dd7a93a8a1756205de1d03eee8c00906af0e5 Reviewed-on: https://gerrit-review.googlesource.com/34570 Reviewed-by: Shawn Pearce <sop@google.com> Tested-by: Shawn Pearce <sop@google.com>
* Add 'rebase="false"' attribute to the <project/> XML.Mike Pontillo2012-03-121-1/+8
| | | | | | | | | | | | | | | This new attribute can prevent 'repo sync' from automatically rebasing. I hit a situation in where one of the git repositories I was tracking was actually an external repository that I wanted to pull commits into and merge myself. (NOT rebase, since that would lose the merge history.) In this case, I'm not using 'repo upload', I'm manually managing the merges to and from this repository. Everything was going great until I typed 'repo sync' and it rebased my manually-merged tree. Hence the option to skip it. Change-Id: I965e0dd1acb87f4a56752ebedc7e2de1c502dbf8
* Revert "Default repo manifest settings in git config"v1.7.8.1Shawn O. Pearce2011-11-301-5/+1
| | | | | | | This reverts commit ee1c2f5717fcc137ab887a4aae8a08d50a539b9a. This breaks a lot of buildbot systems. Rolling it back for now until we can understand what the breakage was and how to fix it.
* Default repo manifest settings in git configVictor Boivie2011-11-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | A default manifest URL can be specified using: git config --global repo-manifest.<id>.url <url> A default manifest server can be specified using: git config --global repo-manifest.<id>.server <url> A default git mirror reference can be specified using: git config --global repo-manifest.<id>.reference <path> This will allow the user to use 'repo init -u <id>' as a shorter alternative to specifying the full URL. Also, manifest server will not have to be specified in the manifest XML and the reference will not have to be specified on the command line. If they are, they will override these default values however. Change-Id: Ifdbc160bd5909ec7df9efb0c5d7136f1d9351754 Signed-off-by: Victor Boivie <victor.boivie@sonyericsson.com>
* Remove extra '/' in RemoteSpecv1.7.7.6Conley Owens2011-11-031-1/+1
| | | | | urljoin appends a '/' if only the domain is in the url path. This change strips that off before creating a RemoteSpec
* Correctly name projects when mirroringv1.7.7.5Conley Owens2011-10-201-4/+8
| | | | | | | | | A bug introduced by relative urls caused projects such as manifest.git to be placed in the root directory instead of the directory they should by in. This fix creates and refers to a resolvedFetchUrl in the _XmlRemote class in order to get a fetchUrl that is never relative.
* Allow remote url to be relative to manifst urlConley Owens2011-09-281-6/+19
|
* sync: Allow -j to have a default in manifestv1.7.6Shawn O. Pearce2011-09-221-0/+9
| | | | | | | | | | | | | This permits manifest authors to suggest a number of parallel fetch operations against a remote server. For example, Gerrit Code Review servers support queuing of requests and processes them in first-in, first-out order. Running concurrent fetches can utilize multiple CPUs on the Gerrit server, but will also decrease overall operation latency by having the request put into the queue ready to execute as soon as a CPU is free. Change-Id: I3d3904acb6f63516bae4b071c510ad57a2afab18 Signed-off-by: Shawn O. Pearce <sop@google.com>
* Support repo-level pre-upload hook and prep for future hooks.v1.7.4Doug Anderson2011-03-111-24/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Make path references OS independentAnthony Newnam2011-01-091-1/+1
| | | | | | | | | Change-Id: I5573995adfd52fd54bddc62d1d1ea78fb1328130 (cherry picked from commit b0f9a02394779c1c9422a9649412c9ac5fb0f12f) Conflicts: command.py
* Added feature to print a <notice> from manifest at the end of a sync.v1.7.1Doug Anderson2010-11-011-0/+62
| | | | | | | | | | | | | | | | | | | | | | | This feature is used to convey information on a when a branch has ceased development or if it is an experimental branch with a few gotchas, etc. You add it to your manifest XML by doing something like this: <manifest> <notice> NOTE TO DEVELOPERS: If you checkin code, you have to pinky-swear that it contains no bugs. Anyone who breaks their promise will have tomatoes thrown at them in the team meeting. Be sure to bring an extra set of clothes. </notice> <remote ... /> ... </manifest> Carriage returns and indentation are relevant for the text in this tag. This feature was requested by Anush Elangovan on the ChromiumOS team.
* Add a 'smart sync' option to repo syncv1.6.9.2Nico Sallembien2010-04-131-3/+29
| | | | | | | | | | | | | This option allows the user to specify a manifest server to use when syncing. This manifest server will provide a manifest pegging each project to a known green build. This allows developers to work on a known good tree that is known to build and pass tests, preventing failed builds to hamper productivity. The manifest used is not "sticky" so as to allow subsequent 'repo sync' calls to sync to the tip of the tree. Change-Id: Id0a24ece20f5a88034ad364b416a1dd2e394226d
* Support detached HEAD in manifest repositoryv1.6.8.5Shawn O. Pearce2009-06-251-1/+1
| | | | | | | | If the manifest repository is on a detached HEAD and we are parsing an XML formatted manifest we should simply set the branch property to None, rather than crash with an AttributeError. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Change project.revision to revisionExpr and revisionIdShawn O. Pearce2009-05-291-15/+17
| | | | | | | | | The revisionExpr field now holds an expression from the manifest, such as "refs/heads/master", while revisionId holds the current commit-ish SHA-1 of the revisionExpr. Currently that is only filled in if the manifest points directly to a SHA-1. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Refactor how projects parse remotes so it can be replacedShawn O. Pearce2009-05-291-6/+20
| | | | | | | | | We now feed Project a RemoteSpec, instead of the Remote directly from the XmlManifest. This way the RemoteSpec already has the full project URL, rather than just the base, permitting other types of manifests to produce the URL in their own style. Signed-off-by: Shawn O. Pearce <sop@google.com>
* Refactor Manifest to be XmlManifestShawn O. Pearce2009-05-291-0/+381
We'll soon be supporting two different manifest formats, but we can't immediately remove support for the current XML one that is in wide spread use within Android. Signed-off-by: Shawn O. Pearce <sop@google.com>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-05-13 12:25:41 +0000