Andy Zimmerman wrote:
On 1/24/06, *Martin Tomes* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>
wrote:
> Are there issues with having one Trac and multiple separate repos?
I cannot see the point in that, if you have multiple repos it implies
independent projects. I know svn:externals can link them but I have
always taken the view that things which belong together live together.
I'm relatively new to Subversion, so forgive me (and please point them
out ) if I'm making bad assumptions. I think one thing that sometimes
causes confusion is the distinction between 'project' and 'product'.
IMO, and open source 'project' and a commercial 'product' are roughly
analogous. In the open source space it makes sense to have one ticket
system per 'project' since projects may be dependent upon one another,
but are rarely so interrelated that a single ticket could apply to
multiple projects. However, the commercial product world is rarely so
clear cut in my experience.
Agreed.
We have multiple products that track issues separately, but on
occasion have interrelated code. They certainly have interrelated
documentation. While I think the Wiki integration in Trac is a stroke
of brilliance, the design decision to advocate separate Trac instances
for separate SVN repositories baffles me.
Look at it differently: nothing prevents you to have multiple projects
each working with
the ''same'' repository, only with a different subset of it.
Currently that subset needs to be fully encapsulated (i.e. only
contained below on path),
but I think it's not a big deal anymore to introduce a more flexible way
to define a restricted
view on a repository.
In the commercial world (at least at my company) adopting Trac would
consequently create multiple sets of Trac documentation needlessly.
Or overly complicate things due to InterTrac links.
I actually think that InterTrac links are a step in the right direction.
Another step is needed, though, because as you said, it's sometimes useful
to share documentation, i.e. the wiki component.
So I've been often asking myself whether it would be useful or not
that a project could ''delegate'' some of its subsystems to other projects.
E.g. you would have project "master", "sub1" and "sub2".
"sub1" and "sub2" would actually use the "master" wiki.
Of course, some kind of component delegation would be
needed to make this work, if at all possible (but I think it is).
While I may not be explaining it clearly, I think there is a strong
case for having one Trac instance connect to multiple SVN repos, for
my purposes, a one-to-one ratio between projects and repos would be
fine. However, I can also see some good reasoning for allowing repos
on a component level, particularly in the instance of shared components.
There's a ticket for adding the support of multiple repositories for a
project.
However, that would be first for repositories sharing a common namespace
of changesets and paths.
For supporting multiple unrelated repositories, you would anyway need a way
to disambiguate changesets and paths, so why not the InterTrac syntax, then?
-- Christian
_______________________________________________
Trac mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac
