Welcome to the Splat alpha!

it looks like following query produces wrong result:

UPDATE reviews_reviewrequest
           SET shipit_count = (
               SELECT COUNT(*)
                 FROM reviews_review
                WHERE reviews_review.review_request_id =
                      reviews_review.id
                  AND reviews_review.public
                  AND reviews_review.ship_it
                  AND reviews_review.base_reply_to_id is NULL)

The problem is fixed with flowing query:

UPDATE reviews_reviewrequest
           SET shipit_count = (
               SELECT COUNT(*)
                  FROM reviews_review 
                 WHERE reviews_review.ship_it
                   AND reviews_review.review_request_id =
                       reviews_reviewrequest.id
                 GROUP BY reviews_review.review_request_id)

Which database are you using?

The ID part does look wrong.. However, the public field is important, and I don't
know that the GROUP BY is correct.

That said, I've done a few test migrations and they seem to work correctly. Strange.

• Status:

  +	NeedInfo

• Tags:

  -	Priority-Medium
  +	Priority-High
  +	Milestone-Release1.0

Actually, the ID part looks correct. I take that back.

So it's important to find out which database this is, because it's probably specific
to that.

I am running MySQL 5.0.51a.
I did usual procedure:

svn update
./manage.py syncdb
this asked me to evolve

./manage.py evolve 
this asked me to run
./manage.py evolve --hint

this command give me a suggestion to run something,
which is gone in history :(

if I run syncdb, I got:

./manage.py syncdb       
There are unapplied evolutions for reviews.
Installing json fixture 'initial_data' from '/space/RB/reviewboard/scmtools/fixtures'.
Installed 6 object(s) from 1 fixture(s)

Unless you're doing development, you should be using rb-site, which will handle all
this for you and will be necessary for future changes to work.

You'd need to have run ./manage.py --execute to make this update work correctly.

I've been testing this change on SQLite, MySQL, and PostgreSQL, and haven't hit a
problem. We even did a trial update of a server with over 80,000 review requests and
saw the ship-it information transition over.

Given that I didn't see ./manage.py --execute in your list, I imagine what happened
is that the query just simply never ran.

oh, right! I did run ./manage.py --execute. It's failed with a complain that some
field already exist in some table (unfortunately I do not remember exact message).
It's may that that I missed it earlier.

I am still using direct svn checkout directory as I stated more than year ago.
Up to know it always worked for me :)

Thanks.

I think you may close this ticket as 'user error'.

Hmm.. That's not so good. That error's going to be important to know, and we're going
to need to see if we can repro this, because I've certainly not hit this yet on the
three systems running MySQL that I've performed upgrades on.

If it complained about a field existing, then it probably just didn't get a chance to
run the query to update. But it's hard to say without knowing more. 

Before sending this, I decided to upgrade the official Review Board server, the demo
server and the Summer of Code server, partially to test this. All three upgrades went
perfectly with no error. So I don't really know what to say here, but it seems to
work. This is also running 5.0.51a, using nightlies and rb-site.

As for using SVN, just a heads up. Soon, we're going to be changing the directory
hierarchy of the reviewboard tree. This will break any existing paths, so you'll need
to update them. I plan to do this just after 1.0 is out the door (which HOPEFULLY is
soon, if RC3 goes well).

• Status:

  -	NeedInfo
  +	UserError

By being a developer myself I know the feeling when you can't reproduce user's
reported problem. I will try to be more accurate next time :)