Re: [Savannah-hackers-public] support for repository(ies) contact/description

[Sylvain Beucler]

Hey,

Another thing I think of is: code linked repositories.

For example, if a repository is a branch of another repository, it can
be optimized (see "forks" in git.or.gz). This saves space. Does
Mercurial has it too?

bzr also tend to have a central '.bzr' repository and subrepositories
that automatically look for ../.bzr or ../../.bzr, etc. (at least
that's how CVS repos are converted to).

So these relationships could be saved in the database so that the
backend can take advantage of them for efficiency (instead of having
people duplicate all of the repository each time an external branch is
created).

-- 
Sylvain

On Thu, Jun 12, 2008 at 08:22:42PM +0200, Sylvain Beucler wrote:
> Hi,
> 
> I think I have some more suggestions about this.
> 
> One goal is to permit different kind of permission models. For
> example: personal repositories, forks, etc.
> 
> So the permissions need to be stored in the database as well.
> It can be a simple model:
>   type enum ('shared', 'single_member', 'single_non_member')
>   owner_user_id int
> 
> or more complex (ACLs)
> table repo_users -- NxN
> (
>   repo_id int,
>   user_id int,
>   type enum ('member', 'admin')
> )
> or something like that.
> 
> Both could be combined (for both flexibility and simplicity), using
> the ACL database, and allowing user to chose pre-configured ACLs
> through the web interface that would mimic shared/single_member/etc.
> 
> -- 
> Sylvain
> 
> 
> On Mon, Jun 09, 2008 at 11:39:59PM +0200, Sylvain Beucler wrote:
> > Hey,
> > 
> > On Mon, Jun 09, 2008 at 10:05:40AM +0200, Aleix Conchillo Flaqué wrote:
> > > On Sun, Jun 8, 2008 at 11:27 AM, Sylvain Beucler <address@hidden> wrote:
> > > >
> > > > My main concern is: will this fit all VCSes? Though, maybe we can just
> > > > add a separate joined table if a VCS requires additional fields .
> > > >
> > > > 'contact' is not used by 'bzr' afaics; maybe that field can be just
> > > > ignored by the bzr backend, or maybe the field can be disabled in the
> > > > edit form (so users don't expect it to be used).
> > > >
> > > 
> > > I think it can also be used, not for any bzr internals, but just to
> > > provide information. That is, there could be a page (read-only) or
> > > existing one, providing repository description and contact
> > > information.
> > > 
> > > >
> > > > The alternate way is to create a specific table for each VCS, but this
> > > > sounds much more difficult to me anyway.
> > > >
> > > 
> > > And it likely has performance penalties. For example, if you want to
> > > obtain all the repositories that 'show_in_source_menu', with one table
> > > it can be done at once with a simple select. The other way would mean
> > > as many selects as activated VCS (which is not a lot).
> > > 
> > > >
> > > > I'd suggest changing 'is_default' to 'show_in_source_menu'.  This way,
> > > > main repositories would be proeminently displayed in the "Source Code"
> > > > menu, as well as in the project homepage. Other repositories would be
> > > > displayed in a separate "other repositories" page; this would exclude,
> > > > for example, experimental repos and obsolete repos (such as CVS repos
> > > > if you switched to Mercurial, but still wish to keep the old CVS
> > > > around :)).
> > > >
> > > > The bottom line is: I think some project will have several main
> > > > repositories (I do :)).
> > > >
> > > 
> > > OK, that makes more sense.
> > > 
> > > >
> > > > I think listing all repositories at once is easier to edit.
> > > >
> > > 
> > > OK.
> > 
> > I agree with everything :)
> > 
> > 
> > We didn't consider the backend more than that, but I don't see any
> > obvious problem there either.