Christopher Lenz wrote:
Am 07.02.2006 um 12:07 schrieb Christian Boos:
...
Why environments should be hidden from each other?
I thought I had explained that, but well. The current
multi-environment support is only provided to make deployment easier,
similar to e.g. SVNParentPath. It's a hack limited to a single layer
that we provide because we don't yet support multiple project per
environment. As soon as we do support multiple projects per
environment, it is likely that we'll drop that support to reduce
complexity in code, configuration and documentation.
Yes, this you explained, however that doesn't tell me why it's a hack or
a bad idea.
Multiple environments per interpreter are also problematic when it
comes to plugin support, because plugins can only be activated for the
complete interpreter.
Ok, this is new to me. I thought that plugins were activated on a
per-environment basis.
Furthermore, limiting the number of environments to one per
interpreter would allow us to make the Environment object and all
Components true singletons, further simplifying the code.
Well, the "pseudo-singleton" Components, with one instance per
Environment are quite
easy to use already. I'm not sure if there would be a lot to gain in
simplifying that further.
So this is the general long-term direction, and adding features that
conflict with that direction should obviously be avoided.
The scope for Trac 1.0 is (and has always been) clearly limited to
single-project support. InterWiki/InterTrac links can help managing
multiple projects, however we should not try to bolt on more
comprehensive features such as retrieving and displaying information
from another environment.
I think that at this point (pre 1.0), it's still undecided how we want
to handle
multiple projects, no?
There are many options.
One seems which seems particularly appealing to me is to keep the current
"one environment = one project", because this is now quite clear
conceptually:
one environment => one db, one repository, one set of milestones, one
wiki
space, etc.
At the same time, it should be possible to "aggregate" several
environments,
in a kind of virtual environment, that would provide an unified view
(one timeline, a common virtual root for browsing the repositories, an
aggregated wiki, consolidated search and queries, etc.)
I think it's worth thinking about it.
In that perspective, having environments know about each other would
be natural.
It would be also quite flexible to add/remove new environments to a group,
maybe even have the possibility of "project hierarchies" in the most
complex
situations (or at least aggregate virtual envs in another virtual env).
Another situation where it make sense to use a sibling environment
is for "moving" objects: e.g. move a ticket from the current environment
to an other environment.
So basically, IMNSHO this feature conflicts with the long-term roadmap
of Trac.
Isn't that too early to tell, given the above proposal?
Of course I would have preferred to discuss this before the merge,
which is why I was a bit pissed about the very short time span you
provided between proposal and merge.
It's not a big deal, I can back out those change, but please consider
the fact that besides theoretical considerations I had some quite positive
feedback on this.
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
