bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jure Zitnik <>
Subject Re: [BEP-0003] Multi product repositories
Date Fri, 15 Mar 2013 14:27:59 GMT
On 3/14/13 9:35 PM, Olemis Lang wrote:
> On 3/14/13, Jure Zitnik <> wrote:
>> On 3/14/13 10:13 AM, Peter Koželj wrote:
>>> 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.
>> Looking at the trac code, we might actually get away w/o introducing new
>> tables (or changes to the translator layer) by just leveraging current
>> 'repository' table.
> Well , the fact is that it might not be desired that users on a given
> product will see code in all repositories ... therefore the soft links
> to limit the scope of sharing .

Yes, that's what we're trying to achieve.

>> afaics the table is a simple attribute (name+value) table for each of
>> the repositories. So one of the possible solutions for the global
>> repositories + soft links would be to simply add another repository
>> attribute that would represent a list of products that 'soft link' the
>> repository...
> /me thinking of queries involving product repos ... what will they look like ?

So, the technical details - the 'repository' table has 3 columns, 'id', 
'name' and 'value'. 'id' is repository key, 'name' + 'value' are 
repository attributes. atm the following attributes are being used: 
'name', 'type', 'url', 'description', 'dir', 'hidden', 'alias'. 
Soft-links could be implemented by using another repository attribute 
named let's say 'product'. So, for each product that would reference a 
specific repository, a new repository attribute would be added to that 
specific repository, with 'name' set to 'product' and 'value' being 
product prefix.

Our implementation of 'DbRepositoryProvider' and 'RepositoryManager' 
would use that ('product') attribute to filter visible/soft-linked 
repositories based on the environment. I would assume that custom 
implementation of those two classes would cover trac/BH code (assuming 
it uses those two classes to access repository information).

The drawback of this approach would be that it doesn't cover 3rd party 
plugin scenarios when accessing 'repository' table(s) directly. Plugins 
running within specific product environments would see all other 
repositories, as the SQL queries wouldn't get translated...

> [...]
> + ... in any case
> PS: I'm not sure of whether we might want to track *now* fork
> relationships among repos , and web UI shortcuts to do such things .
I don't understand what you meant there.


View raw message