The "usermerge" procedure is presently irreversible. Are there plans for a way to make it reversible in case of error? I'm assuming error (and a great deal of tedious mucking about to go back) is inevitable, since the action is taken by humans.
- d.
David Gerard wrote:
The "usermerge" procedure is presently irreversible. Are there plans for a way to make it reversible in case of error? I'm assuming error (and a great deal of tedious mucking about to go back) is inevitable, since the action is taken by humans.
I assume this is about the UserMerge extension? (Note we're not currently using this at Wikimedia.)
It would probably be tricky to implement, but not impossible. Basically would need to record which revisions, log entries, etc got reassigned (potentially many tens of thousands in a single merge event) and their original assignment.
-- brion
- d.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2009/3/25 Brion Vibber brion@wikimedia.org:
David Gerard wrote:
The "usermerge" procedure is presently irreversible. Are there plans for a way to make it reversible in case of error? I'm assuming error (and a great deal of tedious mucking about to go back) is inevitable, since the action is taken by humans.
I assume this is about the UserMerge extension? (Note we're not currently using this at Wikimedia.)
Oh, good!
I say "oh, good!" because such a merge without unmerge has just too much potential for messes, and it was being discussed on functionaries-en-l (the latest incarnation of the Cabal), and I thought from the discussion it was switched on.
It would probably be tricky to implement, but not impossible. Basically would need to record which revisions, log entries, etc got reassigned (potentially many tens of thousands in a single merge event) and their original assignment.
Yeah. Before such a thing is switched on for WMF wikis, we'd need a way to avert the obvious hilarity ensuing from an error. Perhaps not keeping the records forever, but certainly enough for a week or a month's leeway to revert pressing the wrong button.
- d.
2009/3/25 Brion Vibber brion@wikimedia.org:
David Gerard wrote:
The "usermerge" procedure is presently irreversible. Are there plans for a way to make it reversible in case of error? I'm assuming error (and a great deal of tedious mucking about to go back) is inevitable, since the action is taken by humans.
I assume this is about the UserMerge extension? (Note we're not currently using this at Wikimedia.)
It would probably be tricky to implement, but not impossible. Basically would need to record which revisions, log entries, etc got reassigned (potentially many tens of thousands in a single merge event) and their original assignment.
An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.
2009/3/25 Thomas Dalton thomas.dalton@gmail.com:
An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.
I can see such being the case, e.g. prolific sockpuppeting vandals. However, preserving the "original UID" in all merges would likely suffice - I mean, a complete unmerging would be OK in all cases I can think of.
- d.
2009/3/25 David Gerard dgerard@gmail.com:
2009/3/25 Thomas Dalton thomas.dalton@gmail.com:
An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.
I can see such being the case, e.g. prolific sockpuppeting vandals. However, preserving the "original UID" in all merges would likely suffice - I mean, a complete unmerging would be OK in all cases I can think of.
True, you could completely unmerge and them just remerge the parts that should be merged. Rather cruel on the servers if the accounts have been prolific, but it would work. (I'm not sure why we would want to merge sockpuppeting vandals, though - just block them all individually.)
David Gerard wrote:
I can see such being the case, e.g. prolific sockpuppeting vandals. However, preserving the "original UID" in all merges would likely suffice - I mean, a complete unmerging would be OK in all cases I can think of.
- d.
Not sure if you're meaning this or talking about that intangible "new column": Changing the rev_user_text but not rev_user would work for most uses (but merging of anonymous users).
On Wed, Mar 25, 2009 at 9:03 PM, Platonides Platonides@gmail.com wrote:
Changing the rev_user_text but not rev_user would work for most uses (but merging of anonymous users).
Those columns are supposed to be *consistent*. Deliberately making them inconsistent would be a really bad idea. (Although Special:Import often already does . . .)
2009/3/26 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Wed, Mar 25, 2009 at 9:03 PM, Platonides Platonides@gmail.com wrote:
Changing the rev_user_text but not rev_user would work for most uses (but merging of anonymous users).
Those columns are supposed to be *consistent*. Deliberately making them inconsistent would be a really bad idea. (Although Special:Import often already does . . .)
I agree. If you were going to do that you would need to go through every line of code to find anywhere where someone had assumed they were consistent (which could be a lot of places - it's a safe assumption, so why not make it?) and thus written code that would now be broken.
On Wed, Mar 25, 2009 at 6:02 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.
That's a *lot* of extra columns for such a marginal feature. More likely we'd do something like log a blob that has a serialized list of everything changed. (This would require actually figuring out everything that was changed, of course, which already complicates things and probably slows them down.) If we want to revert, we'd load up the blob and build the queries from it.
2009/3/25 Aryeh Gregor Simetrical+wikilist@gmail.com:
On Wed, Mar 25, 2009 at 6:02 PM, Thomas Dalton thomas.dalton@gmail.com wrote:
An extra column in any table with a "user id" column for "original user id" (which would be identical to user id for the vast majority of rows) would be sufficient for most unmerges. There would still be a problem if an account was involved in more than one merge, though.
That's a *lot* of extra columns for such a marginal feature. More likely we'd do something like log a blob that has a serialized list of everything changed. (This would require actually figuring out everything that was changed, of course, which already complicates things and probably slows them down.) If we want to revert, we'd load up the blob and build the queries from it.
That sounds feasible, and allow blobs to expire after a certain length of time unreverted if the space gets onerous.
- d.
On Wed, Mar 25, 2009 at 7:17 PM, David Gerard dgerard@gmail.com wrote:
2009/3/25 Aryeh Gregor Simetrical+wikilist@gmail.com:
That's a *lot* of extra columns for such a marginal feature. More likely we'd do something like log a blob that has a serialized list of everything changed. (This would require actually figuring out everything that was changed, of course, which already complicates things and probably slows them down.) If we want to revert, we'd load up the blob and build the queries from it.
That sounds feasible, and allow blobs to expire after a certain length of time unreverted if the space gets onerous.
What, a few kilobytes per rename? At a handful of renames per day? Not likely to be a problem.
wikitech-l@lists.wikimedia.org