Re: [Savannah-hackers-public] Re: initial mercurial frontend patch

[Sylvain Beucler]

Hi,

On Mon, Apr 14, 2008 at 12:54:45PM +0200, Aleix Conchillo Flaqué wrote:
> On Thu, Apr 10, 2008 at 11:24 PM, Sylvain Beucler <address@hidden> wrote:
> >
> >  - site-wide repositories layout that ease web viewer configuration
> >  (e.g. in ViewVC all repositories are inside one single directory. With
> >  Git there are nested repositories, but there's a repository list to
> >  maintain each time a new repository is added)
> >
> >  - Layout for subprojects:
> >   For Git:
> >    /srv/git/project.git # main repo
> >    /srv/git/project/subrepo.git # secondary repo
> >   For Bzr:
> >     /srv/bzr/project/ # main repo (in /srv/bzr/project/.bzr subdirectory)
> >     /srv/bzr/project/subrepo/ # secondary repo
> >   For Hg:
> >   ?
> >
> 
> A possible solution for this is to use the hgwebdir.cgi script. This
> allows multiple repos and sub repos. For example, a site can have one
> hgwebdir.cgi setup in the apache configuration, the cgi has a
> configuraion file "hgweb.config" where one can setup repositories and
> sub-repositories, like this:
> 
> [paths]
> 
> repo1 = repo1
> repo1/subrepo1 = repo1/subrepo1
> repo1/subrepoN = repo1/subrepoN
> ....
> 
> repoN = repoN
> repoN/subrepo1 = repoN/subrepo1
> repoN/subrepoN = repoN/subrepoN
> 
> 
> The configuration file should be automatically managed by some script.
> 
> So the filesystem layout would be like Bazaar:
> 
> /srv/hg/project/             # main repo (in /srv/hg/project/.hg subdirectory)
> /srv/hg/project/subrepo/ # secondary repo (in
> /srv/hg/project/subrepo/.hg subdirectory)

Good.

Are you sure there isn't a way for hgwebdir to automatically discover
repositories? As the number of repositories will grow, the
configuration file may become big, it will need to be reloaded if we
run it through mod_python, etc. Maybe we could implement this feature.

If this isn't practical we can regenerate the configuration each time
a repository is created, as you mentioned.


> >  - Short paths:
> >   There are also options to trim /srv/git or /srv/svn in some
> >   situations, that'd be something cool for Hg if available :))
> >
> 
> I am not sure what you mean here.

This:
ssh://hg.sv.gnu.org:/myproject
is quicker to type than this:
ssh://hg.sv.gnu.org:/srv/hg/myproject

If we can allow shorter URLs, it's good :)

> >  - Consider managing multiple repositories per project
> >   We'd need that for VCSes too, maybe in a second step)
> >
> 
> The file system layout, ssh and http (read) access I think are
> automatically solved with the example I have written above.
> 
> How do you manage subrepos? I mean, is there any web interface where
> you can add a subrepo? I think this would be necessary in order to
> update configuration files, right?

Yes, there's currently no support for multiple repositories in Savane.


> >  - And as we initially discussed whether it's a "shell restricted" or
> >   "sftp restricted" support. "sftp restricted" is easier but is more
> >   limited.
> >
> 
> I want to try the shell access with limited commands (pull/push),
> using the ssh script found here (hg-ssh option in the link below):
> 
> http://www.selenic.com/mercurial/wiki/index.cgi/SharedSSH

This sounds good.

I think using '. *' (as you mentioned in another mail) is a good
idea. We rely on Unix permissions and group membership for managing
repositorie sauthorization.


> >   For example, if Mercurial supports (or will likely soon support)
> >   server-side hooks (commit notification) or Patch Queue Managers,
> >   this is something we'll only securely provide for a "shell
> >   restricted" setup.
> >
> 
> Yes, it supports hooks (http://hgbook.red-bean.com/hgbookch10.html)
> and queues (http://hgbook.red-bean.com/hgbookch12.html).

A PQM is different than Mercurial's "queues".

A PQM is a process that receives commits in a way or another (e.g. by
mail) and applies them to a repository, and possibly triggering
hooks. This can be used as a replacement for server-side hooks when
the VCS does not support them.


> >   Personal repositories: at Savannah this is not welcome because we
> >   host projects after approving them, so we're not supposed to host
> >   user personal code. However, if this is a wanted feature, we could
> >   imagine allowing per-user project subrepositories
> >   (/srv/hg/savane-cleanup/aleix-branch1/ or something similar).
> >
> 
> What do you mean about personal repositories? Repositories not related
> to a project, but to a user?

Yes. Some users have a tradition of using personal repositories and
merging from each others, rather than using a central repository.

If those users want to work the "decentralized" way, they need a form
of personal repositories.

Instead of giving personal repositories that are not part of a
project, I think they should create a project sub-repository
instead. This makes it clear that we offer hosting for an approved
project (that is, we don't offer hosting for unapproved personal
stuff).

-- 
Sylvain