Issue #282: [feature] subrepositories
|Reported by:||Danil Shkodin|
|Created on:||2017-06-02 22:03|
|Updated on:||2018-05-18 19:44|
Is there any chance, that hg subrepositories will be supported without a need from user to manualy take additional measures? Maybe in a way like built-in TortoiseHg web server serves it.
Despite subprepositories are considered as a 'feature of last resort', there is no alternative in huge projects with reused dependencies. Even though it would take an effort to implement subrepositories publishing, Kallithea might become very favourable with this feature.
Comment by Sean Farley, on 2017-06-02 22:11
Just chiming in about subrepos (not so much Kallithea): I believe the better future will be to use NarrowHG.
Comment by Danil Shkodin, on 2018-01-17 14:18
Comment by Mads Kiilerich, on 2018-01-18 00:34
I do agree that NarrowHG (as pretty much the "opposite" of subrepos) might be a better ... but quite different solution.
Subrepos has many design flaws. Mainly that they are not transitive. They can be mapped in many different ways. Many of them work fine with Kallithea. Many of them are not transitive. It is thus not entirely clear what is requested and how the expectations should be set.
Can you try to clarify what you would request?
Comment by Danil Shkodin, on 2018-01-18 09:47
Thank you for response. The best operating principle, in my opinion, is to create a url subpath for subrepo inside repository url. Just like built into TortoiseHg hgweb does. This enables full transitivity without any effort from user or admin. If this is considered too contradicting to Kallithea internal architecture, [subpaths] feature might be taken into an account.
#.hgsub lib/dependencyA= lib/dependencyA lib/dependencyB= lib/dependencyB [subpaths] (.*)/kallithea/(.*)ProjectName/lib/dependencyA= \1/kallithea/\2ProjectName-dependencyA (.*)/kallithea/(.*)ProjectName/lib/dependencyB= \1/kallithea/\2ProjectName-dependencyB
In this case, I would place these subrepos alongside with the main project. But this is not enough at the moment. I have to make a filesystem symlink on the Kallithea server to make repos/ProjectName/lib/dependencyA to point to repos/ProjectName-dependencyA. And this is a pain. Maybe something like that can be done automaticaly by Kallithea. I can describe the second proposal in more detail on your request.
Please note, that RhodeCode says that subrepo should have an absolute url, but this destroys transitivity and DVCS is not possible, which is described in Mercurial docs. https://docs.rhodecode.com/RhodeCode-1.7.1/usage/subrepos.html https://www.mercurial-scm.org/wiki/Subrepository
Comment by Mads Kiilerich, on 2018-01-19 00:27
I guess the best solution might be to allow repositories to have alternative names. That could be used when repositories are moved or renamed, so they still can be accessed on the old location (until some other repo take that place). It could also allow placing repositories side-by-side, but allow them to be accessed as if they were nested. (Arguably, that is pretty my what subpaths are ... only different). But it would still inherently overload the URL namespace and have the risk of URLs and special paths shadowing each other ...
Comment by Danil Shkodin, on 2018-01-19 10:07
When you push changes to a repo with a subrepo, when changes are being checked, hg checkes internal subrepo folders accordinly to .hgsub. So in filesystem, subrepo has to be exactly there (AFAIK, you cant make [subpaths] work for filesystem paths). If it is not, hg will return an error. This is why I have to do symlinks. So subrepo should be inside a repo and in your case it should be accessed via side-by-side URL . Try it out in your lab, if you got interested.
If URL overload is to take place to allow alternative names, you will have to do a strong and clear priority policy anyways. In this case side-by-side thingy seems excessive, beacause [subpaths] are still required for that.
Comment by Danil Shkodin, on 2018-02-02 10:46
If anyone is interested in this or wants any clarifications on topic, I am open to conversation.
Comment by Thomas De Schampheleire, on 2018-05-18 19:44