Default repository for group

[Mads Kiilerich]

On 04/06/2015 08:34 PM, Jean-Francois Beaumont wrote:
>
> 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.
>

Hmm.

Subrepos are painful. Thanks for providing another reason ;-)

See also 
http://docs.kallithea-scm.org/en/latest/usage/vcs_support.html#working-with-mercurial-subrepositories 
... but that doesn't solve your problem.

One problem with mapping subrepos into the current URL scheme is that it 
will introduce even more risks of collisions. We will have to ignore that.

If you just have one repository like this, I will consider just doing 
some URL rewrite in the web server.

But yes, it could probably make sense to have a default repo. I guess it 
just could be a hardcoded explicit and obscure name and thus not really 
require any UI.

What changes have you made to Kallithea to get what you have?

/Mads
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20150410/f142cada/attachment.html>