Page MenuHomePhabricator

Path fragmenting results in all paths having the same modified property
Closed, ResolvedPublic

Description

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


Version: unspecified
Severity: normal

Details

Reference
bz28122

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:25 PM
bzimport set Reference to bz28122.
bzimport added a subscriber: Unknown Object (MLST).

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