HG Subrepos in the files browser

Issue #489 new
Dave Bell created an issue

The files browser correctly show sub-repos and its revision. However, when clicking on a sub-repo the generate url is incorrect.

An example:

I have 2 repos on disk as follows:

depot/fw/shared/api depot/fw/rrfb

API is a sub-repo of my RRFB project. The tip revision of RRFB is BDC09B54A896 and the tip revision of API is D61236B17CBE.

The file browser for RRFB shows: api @ d61236b17cbe

The generated link for api is: depot/fw/rrfb/files/tip/shared/api

When clicking this link RhodeCode displays an error at the top line of the file browser as follows:

There is no file nor directory at the given path: 'shared/mppt' at revision 'bdc09b54a896'

So the generated link is trying to find the API sub-repo under the RRFB repo and at the tip revision of the RRFB repository.

I should note that I can clone, push and pull the repositories correctly via RhodeCode. So, the .hgsub file is correctly setup. For it I used trivial paths with the [subpaths] markup. For example:

shared/api = shared/api

[subpaths] https://scm.carmanah.com/hg/depot/fw/rrfb/shared/api = https://scm.carmanah.com/hg/depot/shared/api

Comments (2)

  1. Xavier Domont

    I have the same issue in my RhodeCode installation (1.5.4).

    It seems to me that the problem is no so difficult to solve. I looked at the source code of the RhodeCode page, the generated link to the subrepos looks like that:

    <a class="submodule-dir ypjax-link" href="path/to/subrepos">subrepos @ d61236b17cbe</a>

    The problem is that the base url contains "files/tip" or "files/<revision_number>", e.g. http://server/repos/files/tip. Combining with the relative link for the subrepos we obtain: http://server/repos/files/tip/path/to/subrepos instead of http://server/repos/path/to/subrepos

    A simple way to solve the problem would be to replace in the source of the page the relative link "path/to/subrepos" by "../../path/to/subrepos".

    I hope it will help to solve this bug.

  2. Marcin Kuzminski repo owner

    would be good if we could somehow controll if the links should be relative, or absolute. This would also fix this issue

  3. Log in to comment