Changes between Version 3 and Version 8 of Ticket #170


Ignore:
Timestamp:
08/25/2014 03:15:26 PM (5 years ago)
Author:
trev
Comment:

I changed the specification somewhat:

  • Relaxed the requirement to use tags, it's likely not going to work. The alternative is to specific two revision IDs, one for Mercurial and another for Git.
  • Allowed to specify two different roots: one for Mercurial and one for Git. So the root matching the current repository can be used.
  • Prefixed the root setting with _ to distinguish it from the directory settings.
  • Added a _self setting to make sure ensureDeps.py will keep itself updated automatically.

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #170

    • Property Cc fhd added; trev removed
    • Property Priority changed from Unknown to P4
    • Property Owner set to trev
    • Property Platform changed from to Unknown
    • Property Ready set
  • Ticket #170 – Description

    v3 v8  
    2020 * Each repository contains a .sub file formatted like this: 
    2121{{{  
    22 root = https://hg.adblockplus.org/ 
     22_root = hg:https://hg.adblockplus.org/ git:https://github.com/adblockplus/ 
     23_self = buildtools/ensureDeps.py 
    2324buildtools = buildtools 1.0.5 
    24 third_party/googletest = googletest 5.5 
    25 dir = source_repo tag 
     25third_party/googletest = googletest hg:bd26b148913a git:0476e154db5f 
    2626}}} 
    27 * There is an ensureDeps.py script in these repositories that does the following when executed: 
    28   * Parse .sub file to extract the list of subrepositories. 
     27* There is an `ensureDeps.py` script in these repositories that does the following when executed: 
     28  * Parse `.sub` file to extract the list of subrepositories. 
    2929  * For each subrepository check whether the corresponding directory already exists. 
    3030  * If the directory doesn't exist then clone the subrepository there. To determine the repository path, first get the repository path for the current directory (either Mercurial or Git) and assume that the subrepository is available under the same address. If finding repository path fails or cloning from that URL doesn't work, use the fallback root URL specified in .sub file. 
    31   * If the directory exists and is neither a Mercurial nor a Git repository - assume that it is the correct revision. Otherwise try to update it to the specified tag. 
    32   * If the update fails (no such tag) - pull the repository and try again. If it still fails - report failure. 
    33   * Recurse into all subrepositories to process the .sub file there as well. 
    34  * Make build.py call ensureDeps.py as the very first thing and fail if ensureDeps.py fails. We can also integrate this call into the other build systems or at least document in README.md that it needs to be performed. 
     31  * If the directory exists and is neither a Mercurial nor a Git repository - assume that it is the correct revision. Otherwise try to update it to the specified tag/revision. 
     32  * If the update fails (no such tag/revision) - pull the repository and try again. If it still fails - report failure. 
     33  * Recurse into all subrepositories to process the `.sub` file there as well. 
     34  * If the `_self` setting is present: verify that `ensureDeps.py` version running is identical to the one references. If not, replace and re-run it. 
     35 * Make `build.py` call `ensureDeps.py` as the very first thing and fail if `ensureDeps.py` fails. We can also integrate this call into the other build systems or at least document in `README.md` that it needs to be performed. 
    3536 
    3637Downsides of this approach: 
     
    3940 * Changing versions in .sub file needs to happen manually, Mercurial will no longer take care of that if you simply update the subrepository. Also, it will make testing your changes a bit more complicated - once you commit your changes to a subrepository you need to update the .sub file (using tip as subrepo revision is probably the best approach during development). 
    4041 * Everybody has to remember to push changes to a subrepository before changing the dependency - this will no longer happen automatically. Failing to do so will mean that builds will no longer work for everybody else (should hopefully be a rare case that is easily repaired). 
    41  * We have to tag all relevant revisions in our subrepositories so that we can refer to them (e.g. buildtools repository isn't versioned so far). That seems unavoidable because the revision IDs are different between Mercurial and Git, also a tag name is easier to understand in a diff for example. 
     42 * We either have to tag all relevant revisions in our subrepositories so that we can refer to them or use two different revisions: one for Mercurial and one for Git.