Christopher Lenz wrote:
...
IMHO, multi-proj/single-env is a much more intuitive model that is
also more powerful in most respects. A very important advantage is
that the database is shared, making cross-project queries trivial and
cross-project changes atomic. Sharing a central list of users is
simple and natural. Adding a new project doesn't require creating an
environment directory with a database, configuration file, etc: it's
just a new record in the DB.
Agreed, these are (some of) the advantages of the multi-proj/single-env.
There are disadvantages as well, in particular in connection with the
version control support (i.e. this approach would imply that we add
support for multiple repository per environment).
Also, about sharing users: what if one wants to have project specific users?
And project specific permissions?
The same sharing concerns will surface for everything: sharing the enums,
sharing the wiki or not, etc.
Anyway, that would need a major rework of nearly all aspects of Trac,
and I would personally prefer something more gradual, as aggregating
single env would enable.
In that perspective, having environments know about each other would
be natural.
But not under the multi-project/single-env model... the siblings
support assumes "your model", so it shouldn't be in Trac until there's
agreement that it's the approach we should take (which I think is
unlikely, but that's just me).
OK, although one can argue that in the end the approach are even
complementary: you could think about "aggregating" environments
even if those contain multiple projects ;)
I think that at some point in the future I'll try out the aggregation
approach,
and at this time I'll reintroduce the siblings feature.
Hopefully by then we have fixed the env.href stuff :)
(speaking about that, what about my proposal to attach .href to the req ?)
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
