Jani Tiainen wrote: > 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-users -~----------~----~----~----~------~----~------~--~---
