Kallithea issues archive

Just chiming in about subrepos (not so much Kallithea): I believe the better future will be to use NarrowHG.

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?

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

Best.

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 ...

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.

If anyone is interested in this or wants any clarifications on topic, I am open to conversation.