On Feb 7, 2008 6:39 AM, Roan Kattouw roan.kattouw@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.