Here's how I did it: 1) I created a brand new instance of ReviewBoard, updated to the latest version. Set that up and developers started using it. 2) based on a reply from this list (thanks again), I iterated over the review id (check the URL for it) and used wget to retrieve the individual review pages from the old RB instance. 3) I saved the resulting files in a zip, backed up the zip, put it on a couple of backup servers, added a MS Word doc around it and put it into our documentation system, etc. If I really really needed to go back to an old review, it's out there, somewhere. 4) eventually I tore down the old RB instance
Pros: - I got a fresh new install of RB with the latest and greatest version out of the deal - I could set up the new RB at my leisure. I tested the heck out of it, make sure it was all working fine before the dev team cut over to the new instance. - Almost no interruption to the developers. On Sunday evening, I turned off access to the old RB and sent out an email for them to start using the new RB server on Monday morning. They did have to change their hgrc files (we use Mercurial) to point to the new server for "hg postreview" to work correctly. - cruft in the old RB was magically gone from the new RB. Dead projects - gone, old users - gone, etc. etc. - Backups for the new RB site are now much faster and smaller since the DB is clean - I could archive the old reviews at my leisure. Since that server was not in use anymore, no worries about treading in a live, production environment. I set up a script to archive the reviews, ran it and tweaked it several times until I got the output just the way I wanted it. - Total cost was very low: $750 for a new server box; we use Ubuntu, so no OS costs or licensing issues. But I needed an additional Hudson slave anyway, so I recycled the old RB server. Therefore, all in all total cost was $0. Cons: - had to manually re-setup the new RB instance with repos, users, etc. A command line setup for site-specific info would have helped, but manually it only took me an hour or so. - no mechanism to restore the archived reviews into an RB site. Not really an issue for me, but might be one for your site. I guess you could backup the matching SQL DB too, and backup/store both the web pages and the SQL contents. - the archived web pages have html links, etc in them. I briefly thought of writing a script to clean those out, but the value of the archived pages wouldn't increase substantially by going through that work. And the risk the script would remove something important was slim yet possible. I'm betting that no-one (ever) will want to see those reviews again. But in the extreme off-chance they do (e.g. for an audit), the archived pages have key information that would most likely be needed. So comparing all the risk factors, leaving the html links etc in the archived reviews is the lowest risk strategy. John On Thu, Oct 18, 2012 at 2:51 AM, Chris Tooley <cto...@gmail.com> wrote: >> >>> If like to mark them in some way so that they no longer show up in the UI >>> On Oct 18, 2012 3:03 AM, "Christian Hammond" <chi...@chipx86.com> wrote: >>> >>>> I'm sorry, I missed the original e-mail. What do you mean by archiving? >>>> We never delete anything from the database and have no capability to >>>> archive from the database to a file and restore from it, if that's what you >>>> mean. >>>> >>>> Christian >>>> >>> -- Want to help the Review Board project? Donate today at http://www.reviewboard.org/donate/ Happy user? Let us know at http://www.reviewboard.org/users/ -~----------~----~----~----~------~----~------~--~--- To unsubscribe from this group, send email to reviewboard+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en --- You received this message because you are subscribed to the Google Groups "reviewboard" group. To unsubscribe from this group and stop receiving emails from it, send an email to reviewboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.