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


- 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
- 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
- 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.


- 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
- 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.


On Thu, Oct 18, 2012 at 2:51 AM, Chris Tooley <> 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" <> 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
Happy user? Let us know at
To unsubscribe from this group, send email to
For more options, visit this group at
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 
For more options, visit

Reply via email to