One trac env for X repositories ?
Jehan PROCACCIA
I don't want to manage X trac configurations for my X svn repositories :-(
in http://trac.edgewall.org/wiki/TracEnvironment#SourceCodeRepository
it is mention that we can reduce the scope inside a repository, here I want the oposite ! enlarge the scope :
if all my repos are below /var/svn/repos/ -> repos X Y Z ...
I would like to have a kind of repository_dir = /var/svn/repos/ which would eventually browse all repositories below
Unfortunaltly I tried that config, but it keeps yelling that /var/svn/repos/ is not an svn repository :-( !
Any solution ?
thanks.
Jani Tiainen
Unfortunately there is no solution ATM... :)
I would like to do same: have two (or more) repositories binded to
single Trac installation.
This raises some conflicting problems: How to distuinguish revision numbrs.
If you have three repositories, all three have revision 1... How yoy
tell that this is my repository Y rev 1, and another is repo Z rev 1..?
One solution is to use _single_ repository for all your projects.
So on toplevel you have only one repository that contains _all_ of your
projects, that in turn contains trunk, branches and tags etc.
See more about repository layouts at
<http://svnbook.red-bean.com/nightly/en/svn.reposadmin.projects.html#svn.reposadmin.projects.chooselayout>
--
Jani Tiainen
Christian Boos
> Jehan PROCACCIA kirjoitti:
>> is it possible to have only one trac environenment for all my repositories
>> I don't want to manage X trac configurations for my X svn repositories :-(
>> in http://trac.edgewall.org/wiki/TracEnvironment#SourceCodeRepository
>> it is mention that we can reduce the scope inside a repository, here I want the oposite ! enlarge the scope :
>> if all my repos are below /var/svn/repos/ -> repos X Y Z ...
>> I would like to have a kind of repository_dir = /var/svn/repos/ which would eventually browse all repositories below
>> Unfortunaltly I tried that config, but it keeps yelling that /var/svn/repos/ is not an svn repository :-( !
>>
>> Any solution ?
>
> Unfortunately there is no solution ATM... :)
>
Right, see:
http://trac.edgewall.org/wiki/VcRefactoring#SupportforMultipleRepositories
> I would like to do same: have two (or more) repositories binded to
> single Trac installation.
>
> This raises some conflicting problems: How to distuinguish revision numbrs.
There are is a solution to this problem, I believe.
> If you have three repositories, all three have revision 1... How yoy
> tell that this is my repository Y rev 1, and another is repo Z rev 1..?
With some version control backends, this is not an issue, because
revision numbers are globally unique (crypto hashes), and if some
revision numbers are used in more than one repository, then they are
actually the *same* changesets that are shared between those
repositories. In this case, it probably doesn't matter which repository
we pick to display the changeset, so a simple "default_repository"
setting should be enough.
OTOH, with Subversion, each repository has its own r1, so we need a way
to distinguish which r1 we're talking about.
Fortunately, there's already the syntax for restricted changesets,
introduced in Trac 0.10. That syntax is used to "restrict" what's shown
in the TracChangeset view to a given path, like r1/trunk.
Now, if we consider that using multiple repositories is somehow
equivalent to integrating them in a "virtual" tree, where the toplevel
folder is made up of directories corresponding each to a repository, it
becomes natural to use the name of the repository to disambiguate
between revisions. In your example: r1/Y, r1/Z.
For interpreting r1 alone, a "default_repository" setting should also be
enough. Interestingly, this also solves the problem of transitioning
from the single repository situation to the multiple repository one:
simply set the repository which was formerly the only one to be the
default one when you add more repositories. That way, all previously
existing changeset links will continue to be meaningful.
There's similar situation for source: links. The only additional problem
I see could be that the name of a repository also happened to be the
name of a toplevel folder in the "default_repository".
I believe this could be seen quite often, when people are transitioning
from a monolithic repository, containing toplevel projects, to a
multi-repository setup, with each of the former project getting its own
repository. If you keep the old repository around as read-only, in order
to make to old links work, you could have trouble to decide if
source:X/doc is the "doc" folder in repository X (the new one), or the
"X/doc" folder in the legacy repository.
I don't see a perfect solution to this.
One idea could be to rename the repositories differently in order to
avoid the clash, but that's not always possible, I guess.
Another would be to allow for aliases, in the same way we do it for
intertrac prefixes. That would in addition be handy for being able to
keep the links short (i.e. you could write r1/x even if the actual
repository name is x_project_repository). But this only provides a way
to write unambiguous links, not to figure what to do in case of ambiguity.
I think that if the first component of the path in a restricted
changeset link or in a source: link corresponds to the name of a
repository, then we always take it to be a link for that repository,
even if a similar path could exist in the "default_repository".
It's only if no path is specified (i.e. a normal changeset), or if the
first component of the path doesn't correspond to a repository name that
the "default_repository" will be used.
>
> One solution is to use _single_ repository for all your projects.
>
> So on toplevel you have only one repository that contains _all_ of your
> projects, that in turn contains trunk, branches and tags etc.
Given the transition model explained above, that sounds like a good
thing to do while waiting for the multiple repository support ;)
-- Christian