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
_______________________________________________
kallithea-general mailing list
[email protected]
http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
