Hi Marco,

On Wed, Feb 24, 2021 at 9:09 PM Marco Antoniotti
<marco.antoniotti@unimib.it> wrote:
>
> Hi Ray
>
> yes.  That is exactly my question.  I have WITH-CONTEXTS and OOK (let's say).  Both now must have WITH-CONTEXTS-SITE and OOK-SITE repositories.  Must why have their own group?  Can they be in more than one group, like UNIX groups?
>
> I know I should RTFM, but it is easier to ask :)

In this case, it's better to ask, because the FM won't supply the
answer. The problem is the setup of the URL structure of the
https://common-lisp.net/ site, with all projects being subdirectories
on the same top-level domain. The GitLab pages functionality that we
use to host the project sites, wasn't designed with that in mind;
instead, it was designed to be run on its own top-level domain where
all subdomains get rerouted to GitLab Pages.

In order to be able to use GitLab Pages with our use-case, I've hacked
around a restriction or two in the way GitLab manages its published
web page assets. In order to keep things simple (that is: manageable
with Apache mod_rewrite), I needed a fixed transformation from
https://common-lisp.net/project/<project-name>  to an on-disc path
that might or might not exist when /project/<project-name> does not.
In order to support the group/repo structure where
*/<project-name>-site is supported as a mapping, I no longer have a
fixed mapping, because all '*' paths (group names) need to be checked
for existence (GitLab stores its published webpages hierarchically).

Those are all *explanations*, not solutions. I'm thinking about
available solutions, but don't have one quickly: checking more paths
than the available fixed mapping, might run into clones of the repo.
If that happens, which one of them is the true and leading one? (That
is: what should the software do if there are ehuelsmann/ook-site,
mantoniotti/ook-site and with-contexts/ook-site?)


Regards,

--
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.