<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 04/06/2015 08:34 PM, Jean-Francois
Beaumont wrote:<br>
</div>
<blockquote
cite="mid:CACNqqAQ0ErHa44WK0n5USomu0ZV6CiapcmZjRh3iVu8q32UeCw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_quote">
<div dir="ltr">
<p
style="margin:0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">Hi,</p>
<p
style="margin:0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px"><br>
</p>
<p
style="margin:0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">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.</p>
<p style="margin:10px 0px
0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">On
the current server, I have a directory layout like so:</p>
<div style="margin:10px 0px
0px;padding:0px;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">
<pre style="margin-top:0px;margin-bottom:0px;padding:5px 10px;font-family:Consolas,Menlo,'Liberation Mono',Courier,monospace;font-size:12px;line-height:1.4;border:1px solid rgb(204,204,204);border-radius:3px;word-wrap:normal;background:rgb(245,245,245)">group1/
group1/project2/.hg
group1/project2/project3/.hg
</pre>
</div>
<p style="margin:10px 0px
0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">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.</p>
<p style="margin:10px 0px
0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">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?</p>
<p style="margin:10px 0px
0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">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.</p>
<p style="margin:10px 0px
0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">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.</p>
<p style="margin:10px 0px
0px;padding:0px;word-wrap:break-word;color:rgb(51,51,51);font-family:Arial,sans-serif;font-size:14px;line-height:20px">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.</p>
</div>
</div>
</div>
</blockquote>
<br>
Hmm.<br>
<br>
Subrepos are painful. Thanks for providing another reason ;-)<br>
<br>
See also
<a class="moz-txt-link-freetext" href="http://docs.kallithea-scm.org/en/latest/usage/vcs_support.html#working-with-mercurial-subrepositories">http://docs.kallithea-scm.org/en/latest/usage/vcs_support.html#working-with-mercurial-subrepositories</a>
... but that doesn't solve your problem.<br>
<br>
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.<br>
<br>
If you just have one repository like this, I will consider just
doing some URL rewrite in the web server.<br>
<br>
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.<br>
<br>
What changes have you made to Kallithea to get what you have?<br>
<br>
/Mads<br>
</body>
</html>