Mailing-List: contact bloodhound-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: bloodhound-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of brane@wandisco.com designates
 74.125.83.41 as permitted sender)
Message-ID: <51408CF7.6050807@wandisco.com>
Date: Wed, 13 Mar 2013 15:28:07 +0100
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@wandisco.com>
Organization: WANdisco
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130307 Thunderbird/17.0.4
MIME-Version: 1.0
To: bloodhound-dev@incubator.apache.org
Subject: Re: [BEP-0003] Multi product repositories
References: <51405952.1060902@digiverse.si>
In-Reply-To: <51405952.1060902@digiverse.si>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

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.
>
> Current implementation does not 'productize' repositories, all
> repositories are global. In my opinion this should be changed to have
> per product repositories. Practically this would mean adding
> 'repository' table to the translated table list.
>
> 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 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.
>
> Any comments/suggestions on this?

IIRC, a "repository" in Trac implies an index of all changes. With
per-product repositories, you'd be duplicating all those indexes, which
can cause serious database size explosion.

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.

-- Brane


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com