darcs

Issue 1513 reconstruct nosy list on all bugs

Title reconstruct nosy list on all bugs
Priority bug Status resolved
Milestone Resolved in
Superseder Nosy List Serware, darcs-devel, dmitry.kurochkin, kowey, thorkilnaur
Assigned To
Topics BugTracker

Created on 2009-08-06.21:14:18 by kowey, last changed 2009-10-23.23:31:44 by admin.

Files
File name Uploaded Type Edit Remove
restore-issue1513-goof.py kowey, 2009-08-10.12:34:29 application/octet-stream
restore-issue1513-goof.py kowey, 2009-08-10.12:49:58 application/octet-stream
Messages
msg8040 (view) Author: kowey Date: 2009-08-06.21:14:14
Argh, I messed up the nosy list on a whole bunch of bugs.  The good news is that
it should be possible to restore these lists, but it'll take a bit of
programming work, probably best in Python.

I wanted to remove David from a bunch of bugs (he expressed an interest in
this), so using roundup-admin, I created a list of all bugs owned by David.

Then with a little scripting, I created a gigantic

 set issueXXX,..,issueYYY nosy=-droundy

While this appeared to remove David, I was puzzled as to why it was adding and
removing users seemingly at random.  Only much later did I realise that what it
(must have) done was to infer a nosy list for issueXXX (i.e. by removing droundy
from that list), and that apply that SAME list to ALL the issues!

The good news is that we can query the history for all issues, and so we can
fairly easily look up all the instances where this happened, for example, by
searching for events such as:
('534', <Date 2009-08-06.17:45:16.500>, '1', 'set', {'nosy': (('+', ['25',
'996', '991', '17', '1555', '178', '517'])

Note in particular the date.  So in principle, we just have to reverse these
actions, removing the users we added (and more importantly), re-adding the users
we removed (sans user3, droundy).

I did have a little voice in my head telling me I should have made a backup...
msg8065 (view) Author: kowey Date: 2009-08-10.12:34:29
Hi Simon,

Is there any chance you would have a few minutes to look at the attached
restore-issue1513-goof.py, just to sanity check it?

It's a Python script that generates a set of roundup-admin invocations (*) that
restores the nosy list for a bunch of issues whose nosy lists I accidentally
clobbered.  See the history to this bug for details.

(*) Because I don't know if I can update the hyperdb through the roundup API
directly and preserve consistency; I imagine I can, though
Attachments
msg8066 (view) Author: kowey Date: 2009-08-10.12:49:58
Updated with a bug fixed and range extended to all issues
Attachments
msg8081 (view) Author: kowey Date: 2009-08-10.22:25:35
I've gone ahead and run my script.  It seems to work (imperfectly, but nothing a
little regular expression couldn't fix).  Phew, done.
History
Date User Action Args
2009-08-06 21:14:18koweycreate
2009-08-10 12:34:32koweysetfiles: + restore-issue1513-goof.py
nosy: kowey, simon, thorkilnaur, dmitry.kurochkin, Serware
status: unread -> unknown
messages: + msg8065
assignedto: kowey -> simon
2009-08-10 12:50:00koweysetfiles: + restore-issue1513-goof.py
nosy: kowey, simon, thorkilnaur, dmitry.kurochkin, Serware
messages: + msg8066
2009-08-10 22:25:37koweysetstatus: unknown -> resolved
nosy: kowey, simon, thorkilnaur, dmitry.kurochkin, Serware
messages: + msg8081
assignedto: simon ->
2009-08-25 18:14:16adminsetnosy: + darcs-devel, - simon
2009-08-27 14:22:23adminsetnosy: kowey, darcs-devel, thorkilnaur, dmitry.kurochkin, Serware
2009-10-23 22:46:12adminsetnosy: + serware, - Serware
2009-10-23 23:31:44adminsetnosy: + Serware, - serware