|
|
Trac Users |
>> Any solution ? > Unfortunately there is no solution ATM... :) http://trac.edgewall.org/wiki/VcRefactoring#SupportforMultipleReposit... > This raises some conflicting problems: How to distuinguish revision numbrs. OTOH, with Subversion, each repository has its own r1, so we need a way Now, if we consider that using multiple repositories is somehow For interpreting r1 alone, a "default_repository" setting should also be There's similar situation for source: links. The only additional problem I believe this could be seen quite often, when people are transitioning I don't see a perfect solution to this. One idea could be to rename the repositories differently in order to Another would be to allow for aliases, in the same way we do it for I think that if the first component of the path in a restricted > One solution is to use _single_ repository for all your projects. > So on toplevel you have only one repository that contains _all_ of your -- Christian Jani Tiainen wrote: Right, see:
> 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 :-( !
> I would like to do same: have two (or more) repositories binded to There are is a solution to this problem, I believe.
> single Trac installation.
> If you have three repositories, all three have revision 1... How yoy With some version control backends, this is not an issue, because
> tell that this is my repository Y rev 1, and another is repo Z rev 1..?
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.
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.
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.
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.
I see could be that the name of a repository also happened to be the
name of a toplevel folder in the "default_repository".
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.
avoid the clash, but that's not always possible, I guess.
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.
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.
Given the transition model explained above, that sounds like a good
> projects, that in turn contains trunk, branches and tags etc.
thing to do while waiting for the multiple repository support ;)