Am 08.02.2006 um 13:09 schrieb Christian Boos:
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).
Sure, you have a repository per project. Some aspects of the current
Environment will be at the project level, some remain at the
environment level.
Also, about sharing users: what if one wants to have project
specific users?
Project specific users are "project members". The user profile itself
can be shared across projects, though, which makes a lot of sense IMO.
And project specific permissions?
The same sharing concerns will surface for everything: sharing the
enums,
sharing the wiki or not, etc.
Sure, the details of this need to be sorted out.
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.
Multi-project support is a "Trac 2.0" feature, and yeah, it'll
require quite a bit of work. But it's not necessarily a complete
rewrite, and mostly automated upgrading should be possible, at least
from a single environment.
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'm not sure I see the use case then. The whole multi-environment
approach is IMO a workaround for not having multi-project support.
Hopefully by then we have fixed the env.href stuff :)
(speaking about that, what about my proposal to attach .href to the
req ?)
req.href is actually part of the WSGI branch.
Cheers,
Chris
--
Christopher Lenz
cmlenz at gmx.de
http://www.cmlenz.net/
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
