incubator-bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Koželj <pe...@digiverse.si>
Subject Re: [BEP-0003] Multi product repositories
Date Thu, 14 Mar 2013 09:13:37 GMT
Maybe there is a solution in between pure soft links and repository table
translation.
I would go with links which is classical many-to-many table between
products and repositories.
We can then translate the repository table based on the links table instead
of the repository table itself.

If we can can pull this off on the SQL translation level we get "global
repositories" with translated view in product context almoast for free.

Peter

On 13 March 2013 16:43, Olemis Lang <olemis@gmail.com> wrote:

> On 3/13/13, Branko Čibej <brane@wandisco.com> wrote:
> > On 13.03.2013 11:47, Jure Zitnik wrote:
> >> Hi,
> >>
>
> :)
>
> >> one thing that has not been discussed in relation to multi-products
> >> yet are VCS repositories.
> >>
>
> they should be global , and SQL queries will not be translated
>
> >> Current implementation does not 'productize' repositories, all
> >> repositories are global.
>
> that's correct
>
> >> In my opinion this should be changed to have
> >> per product repositories. Practically this would mean adding
> >> 'repository' table to the translated table list.
> >>
>
> -1
>
> >> Olemis on the other hand suggested (in another thread) that all
> >> repositories should be global and have 'soft links' to products which
> >> would allow for repository reusal in different product contexts.
> >>
>
> I recall ...
>
> >> I would suggest we go with the first option (per-product repositories)
> >> for now and add support for 'global' repositories and 'soft links' at
> >> the later stage.
> >>
> [...]
> >
> > IIRC, a "repository" in Trac implies an index of all changes.
>
> +1
>
> > With
> > per-product repositories, you'd be duplicating all those indexes, which
> > can cause serious database size explosion.
> >
>
> ... and also an unnecessary repetition of changeset caching procedure
> wasting valuable CPU time thus seriously degrading overall performance
> for no good reason .
>
> > Consider, for example, the ASF: there is one repository with well over a
> > million revisions and ~100 "products" stored in it, so you're looking at
> > two orders of magnitude more data for repository indexing if you
> > duplicate the repos in a bloodhound instance for each project.
> >
>
> This is a fact O(p * r) ... and considering that r > p will be a
> frequent scenario that becomes O(p^2)
>
> --
> Regards,
>
> Olemis.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message