On 3/14/13 9:35 PM, Olemis Lang wrote:
On 3/14/13, Jure Zitnik <[email protected]> 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.
Cheers,
Jure
