Using subrepository

(Cédric Krier) #1

Currently we are using hgnested to ease development of all repositories. As the maintainer of hgnested, I start to be tired of burden of maintaining it over each new Mercurial release because the internal API change almost at each release.
Also hgnested does not ensure the coherence of the nested tree. For example, it does not clone new repositories, it fails when switching to an other branches that a nested repository does not have etc.

So I propose to use the subrepository builtin feature of Mercurial which is more mature now than when we started hgnested and which is standard feature.
The main repository which I propose to name development will contain this subrepo structure:

  • trytond
  • tryton
  • sao
  • proteus
  • modules
    • account
    • party
    • …

The repository will contain a hook that manage symlink inside trytond/modules (must create missing and remove unknown based on .hgsub configuration). This hook could be added to the update operation.

The workflow will be that every development on default branch should be committed from the development repository. This will ensure to update the .hgsubstate (in case of mistake, the developer will have to manually update the development repository with the latest revision of all subrepo).

The back-port to older branches will be pushed on each individual repository and when everything have been back-ported, the branches of development repository will be updated.

The release process will stay as-is but a new branch will be created for the new series on the development repository and the default branch will be updated.

For the review, individual patches may be uploaded to Rietveld (or nested one). When we will have a patch mailing list, individual patch could be sent using patchbomp or a manual diff with the option --subrepos from development repository.

Optionally, we could use this new repository to trigger a build that runs all the tests.

(Vincent Bastos) #2

It makes sense to use another existing tool. It does seem a little more effort to use than hgnested. It might be worth running a trial on the side to run all the functions that are currently being used with hgnested.

(Sergi Almacellas Abellana) #3

I’m not sure if this is really required. If the modules is directory is a symlink to trytond/trytond/modules and we checkout the modules into the module directory it will work without problems.

(Cédric Krier) #4

I do not understand what it means.

subrepository can not be in a subrepository except if it is defined as a subrepository in the subrepository. But we do not want that trytond contains all the modules as subrepositories because we do not want to have to commit in trytond because a module changed.

(Sergi Almacellas Abellana) #5

Then we need the hook as you described.

(Pulkit Goyal) #6

Due to lot of work going on to implement new features like partial clone, we are refactoring our API’s. I have hacked hgnested to support hg 4.6. You can pull changeset from https://bitbucket.org/PulkitG/hgnested/commits/all

Just FYI, subrepos are a feature of last resort (https://www.mercurial-scm.org/wiki/FeaturesOfLastResort) and I won’t advise you to use it because in past there have been security issues because of subrepos.

Thanks!

(Cédric Krier) #7

I understand that mercurial API’s need to evolve but this create too much work too follow the changes for a small extension like hgnested. Especially if standard alternative exists now that provides even more features.

I know but I think it applies to our use case. hgnested is probably also a last resort extension.

As far as I can see it was about using Git sub-repository. Indeed if Mercurial had no security issues, it will be suspicious. But having some, means that people are auditing it and so there are less issues. :wink:
Indeed we do not know if hgnested does not have security issues.

Have you another proposal?