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.
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.
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.
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.
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.
Indeed we do not know if hgnested does not have security issues.
The repository is published at https://hg.tryton.org/tryton-env/
The .hgsub is ordered for the modules by alphabetic order, it is better for maintainability to keep the order.
I propose to all developers to push using it for few weeks to see if the workflow works correctly. If it is the case, we will deprecate hgnested on the website and for advise tryton-env.
I had to recreate the tryton-env repository because I used ../ for the target in .hgsub to reach the canonical repositories. But unfortunately, the prevent to clone locally the repository (if you do not reproduce the same structure). I found this was very annoying for work, so I recreated it using local path and configured hgweb and mercurial-server to serve the repositories from inside tryton-env repository.
If you have already cloned the repository, you must delete it and re-clone a new one. Sorry for the inconvenient.
I personally made all the operations I used to do: add single feature, make global changes, back-port patches and make releases. I must say that the subrepo workflow is pretty convenient for me. So for me, the experiment is a success.
To fully migrate, we still need:
It won’t work because review.py use shell commands to get the information from mercurial whereas hgreview directly plugs into mercurial internals. Unfortunately the function hgreview is using to get the modified / added / deleted files works can be executed on subrepos but do not return this data (Mercurial: 87bfd1703597 mercurial/context.py).
Of course using itersubrepos is an option I plan to implement but not right now.
I’m using upload.py and those two features are the ones which I’m missing.
I have a local modified version of upload.py which changed the default server to upload, so not really missing the configuration too much as most of the time I only work with one codereview server.
Agree that implementing on upload.py will be better. I’m currently using upload.py because hgreview does not work on latest py3
