![]() Will create a subrepo folder mysubrepo inside your parent repository.Īdding it to the. Your original repository: C:\Shared\MySubRepoĬloning this as a subrepo into another repository by command line hg clone C:\shared\mysubrepo <- Note the lower cases! TortoiseHG fails to commit to the subrepository because it handles folder names case-sensitive! In one of my repositories committing of one of my changed subrepo modules failed with message "abort: mysubrepo: no match under directory!" hgsubstate file in the main repository root." If a subrepo is included in the file list of a commit, the subrepo is committed along with the other changes, updating the. When Mercurial considers a subrepo as dirty, it will appear in the commit tool as a special entry in the file list with a status of S. ![]() "TortoiseHg 1.0 introduced rudimentary support for subrepositories, and only in the commit / status tool. Is this scenario not supported or am I doing something wrong? In Tortoisehg customer1\project1 is displayed with status S (subrepo)īut when commiting I get a message abort: customer1/project1: no match under directory! If modify the file Customer1\Project1\foo.txt and commit from the root it works >hg ci -m "command line commit"Ĭommitting subrepository customer1\project1 hgsub file under root looks like Customer1\Project1=Customer1\Project1 I have a directory structure like this: root Optionally, we could use this new repository to trigger a build that runs all the tests.I can't get Tortoisehg (1.0) to work with subrepos 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. 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.įor the review, individual patches may be uploaded to Rietveld (or nested one). 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. hgsubstate (in case of mistake, the developer will have to manually update the development repository with the latest revision of all subrepo). The workflow will be that every development on default branch should be committed from the development repository. This hook could be added to the update operation. The repository will contain a hook that manage symlink inside trytond/modules (must create missing and remove unknown based on. The main repository which I propose to name development will contain this subrepo structure: 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. For example, it does not clone new repositories, it fails when switching to an other branches that a nested repository does not have etc. 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.Īlso hgnested does not ensure the coherence of the nested tree. ![]() Currently we are using hgnested to ease development of all repositories. ![]()
0 Comments
Leave a Reply. |