Default repository for group

Jean-Francois Beaumont jean-francois.beaumont at mail.mcgill.ca
Mon Apr 6 20:34:56 EDT 2015


Hi,


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.

Thanks!

JF
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20150406/9da60d2f/attachment-0001.html>


More information about the kallithea-general mailing list