On 10/01/12 19:11, Olemis Lang wrote:
On Tue, Jan 10, 2012 at 2:08 PM, Olemis Lang<[email protected]> wrote:
On Tue, Jan 10, 2012 at 11:06 AM, Olemis Lang<[email protected]> wrote:
[...]
maybe a few fields like creation time , owner , project logo (i.e. project fields
used in trac.ini ;) should also be considered for inclusion in there . I like the
idea of being able to consider projects just like if they were yet another Trac
environment inside an environment . That way e.g. external environment may be
merged within another and become a project located at a given level of project
hierarchy . All that metadata should be kept and reused in new project living
(<= oh ! I really wanted to say that ... life is beautiful :) inside target
environment . Another goal might be to have all this implemented causing the least
impact over existing plugins , preferably no side-effects .
This makes me wonder whether it would be appropriate to have :
- project_config table : basically a mirror of trac.ini inside
database (fields TBD ;)
... or maybe separate project config files in trac.ini ?
sorry my mistake . I wanted to say :
... or maybe separate project config files similar to trac.ini in conf folder ?
I think split configuration files might well make sense at some point
but I probably wouldn't go with that straight away. For now, assuming
that we are going to make use of the trac.ini file, I would argue that
we have a reasonable example of how to describe different projects in
the form of the repositories section. Does a "short_name.property =
value" form make sense to others?
If we do go with splitting configs at some point, would it be complete
madness to have some mechanism to include other files so that
administrators can split their configuration files as they wish?
Cheers,
Gary
