Default repository for group

Issue #122 invalid
JF created an issue

I am looking for the best way to migrate a large user base and a great number of repositories from hgweb to Kallithea. Looking at what I can do, the repository group is a useful concept but it conflicts with the sub repositories I am currently using.

On the current server, I have a directory layout like so:

group1/
group1/project2/.hg
group1/project2/project3/.hg

So I will not clone group1 but I will do so for group1/project2 and for group1/project2/project3. Sadly, if I try to scan this directory structure, only group1 and group1/project2 will be made available in K. This is a problem for me.

Granted, this is not the best organization of repositories but since I have a large quantity of users to migrate and a large code base, I cannot simply say that group1/project2 cannot be a repository unilaterally so I am looking for options. Maybe some support for this is already available?

If not, I've given this some thinking and came out with the idea of the default repository for group. With this new functionality, group1/project2 would not be a repository but a group so let's call it group1/group2 from now on. In that context, if someone tries to clone group1/group2, the user would be given automatically the default repository. I'm thinking that it should be a repository inside of group1/project2 group. It would make sense that this default repository could be set in the UI.

However, with the limited knowledge of the code I have right now, I'm not able to propose a complete solution that would include UI changes so I tested something simpler so that if someone tries to clone group1/group2, it automatically clone the repository inside group2 that as the same name as that group, i.e. group1/group2/group2.

I'm actually satisfied by the hacky solution but I'm wondering if a more formal solution would be useful to other people out there. For instance, it would be nice to offer automatic support for inner/sub repositories right from import/scan so this would be painless as possible for the admins.

Comments (3)

  1. Mads Kiilerich

    This is an issue tracker, not a support forum. Please use the mailing list to interact with the community.

  2. Log in to comment