On Feb 7, 2008 6:39 AM, Roan Kattouw <roan.kattouw(a)home.nl> wrote:
Anyway, something that touches as deep upon the core
code as Namespace
Manager does should be in its own branch IMO. The perceived problem with
branches is nonexistent if there's someone around to svnmerge every week
or so and resolve conflicts.
They still have to get checked in. I don't think it would be such a
big deal to write up the core parts of this, in terms of needing to
branch. I envision a process like this:
1) Write up a namespace-handling class and centralize all reference to
namespace numbers and namespace-related variables there. Change
things that currently refer to namespace numbers directly (i.e.,
everything) to use the class' methods instead.
2) Create an appropriate database table and populate it with the
default namespace settings.
3) Gradually change the namespace class (which could, in fact, be
Namespace . . . although not under that name for long, given that it's
a keyword in PHP 5.3) to use the database in addition to the
namespace-related globals. Specifically, set it so it will obey any
LocalSettings.php customizations first, then what's in the database,
then DefaultSettings.php default namespace settings (if it looks at
those at all). This preserves backward compatibility in all respects.
Some way will be needed to distinguish the default settings from
customized ones, of course.
4) Create a namespace manager. This will allow modification of
namespaces as you would expect. For as long as setting stuff in
LocalSettings.php is allowed (which may be forever), it will gray out
any options that are hardcoded there.
None of those steps is a breaking change, and they can all be done in
small pieces. There's no point in creating a giant branch that you
have to keep up to date (which SVN makes a big headache) and which
will then have to be merged all at once.
A similar procedure could be followed for an in-wiki permissions editor.