Last modified: 2011-04-08 15:31:17 UTC
Comment: Tag for version 0.4.1 Modified paths: / (added) /tags (added) /tags/extensions (added) /tags/extensions/SemanticInternalObjects (added) /tags/extensions/SemanticInternalObjects/REL_0_4_1 (added) Comment: Per Jarry1250 on IRC: fix for r81469: accept StubObject in Message::inLanguage(); was breaking api.php?action=query&meta=allmessages Modified paths: / (modified) (diff) /trunk (modified) (diff) /trunk/phase3 (modified) (diff) /trunk/phase3/includes (modified) (diff) /trunk/phase3/includes/Message.php (modified) (diff) Comment: deleting erroneously created directory Modified paths: / (deleted) /tags (deleted) /tags/extensions (deleted) /tags/extensions/SemanticFormsInputs (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1 (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs (deleted) Will poke at it later
Part of this will be the path repopulation... On newer improted revs, it seems to be alright... This might actually be a WONTFIX..? As working out what was already there (unless it's common or below?), would need to have a modified status Comment: releasing version 0.4.1 Modified paths: / (added) /tags (added) /tags/extensions (added) /tags/extensions/SemanticFormsInputs (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1 (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/COPYING (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/README (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SFI_Inputs.php (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SFI_Settings.php (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs.i18n.php (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs.php (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/COPYING (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/README (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/SFI_Inputs.php (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/SFI_Settings.php (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/SemanticFormsInputs.i18n.php (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/SemanticFormsInputs.php (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/images (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/libs (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/SemanticFormsInputs/skins (deleted) /tags/extensions/SemanticFormsInputs/REL_0_4_1/images (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/libs (added) /tags/extensions/SemanticFormsInputs/REL_0_4_1/skins (added)
We also don't have a NOOP or similar, if it wasn't actually changed on that path. If we added one to the ENUM (bleugh), we can just apply that, unless we explicitally know what happened to a path entry..? In most cases, it's the common subpaths that are the issue
Hah I hadn't realized path fragmenting would lead to this. Using a noop action flag sounds good to me.
Adding to the enum is ok... Just wondering how exactly to get it to fix the paths on a back populate.. Delete all, and re-read paths from svn. We've then got the actions for the explicit paths, and everything else can just be applied noop?
r85671 Added NOOP (N). If it's an "N" path, don't display it, just use it for searching
