On 3/13/13, Branko Čibej <[email protected]> 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.
