into  kite-hub.kitebird.com:/src/extern/MySQL/bk/mysql-5.1

  Backport option description change from 5.1 to 5.0.

into  zim.(none):/home/mikael/bug16370

into  production.mysql.com:/usersnfs/gbichot/mysql-5.1-new

(nothing to document, this bug was not released).

into  zim.(none):/home/mikael/bug16370

into  zim.(none):/home/mikael/bug16370

into  zim.(none):/home/mikael/bug17127

into  zim.(none):/home/mikael/bug17127

into  mysql.com:/home/hartmut/projects/mysql/bk-clean/5.1

declared in the 'for' statement is not portable, some compilers
still don't implement this ANSI C++ specification (Bug #14995)

into  zim.(none):/home/mikael/bug16370

into  zim.(none):/home/mikael/bug16370

into  zim.(none):/home/mikael/bug15961

New error message

into  production.mysql.com:/usersnfs/gbichot/mysql-5.1-new

into  mysql.com:/home/jimw/my/mysql-5.1-clean

into  production.mysql.com:/usersnfs/gbichot/mysql-5.1-new

into  zim.(none):/home/mikael/bug16370

  Revise option description. And let's put it in the proper
  lexical order within the option list.

New test case (bug was already fixed)

into  mysql.com:/home/jimw/my/mysql-5.1-clean

into  mysql.com:/usr/local/mysql/tmpbuild-5.1

  Small change to enable sending of mails from Windows bk clones

into  mysql.com:/usr/local/mysql/mysql-5.1-new

into  perch.ndb.mysql.com:/home/jonas/src/mysql-5.1-new

into  production.mysql.com:/usersnfs/gbichot/mysql-5.1-new

- detect the need for row-based binlogging not at execution stage but earlier at parsing stage; needed for example for CREATE TABLE SELECT UUID().
- more tests of this mixed mode.

into  shellback.(none):/home/msvensson/mysql/mysql-5.1

into  mysql.com:/home/jimw/my/mysql-5.1-clean

into  mysql.com:/home/jimw/my/mysql-5.1-clean

into  mysql.com:/home/jimw/my/mysql-5.1-clean

into  mysql.com:/home/jimw/my/mysql-5.1-clean

into  production.mysql.com:/usersnfs/rburnett/mysql-5.1-bug17173

Bug # 17894 - Comparison with "less than" operator fails with range partition

The problem here was that on queries such as < 3, the range given is NULL < n < 3.
The null part works correctly where the null value is stored in rec[0] and the
field is marked as being null.  However, when the 3 is processed, the 3 is places
on rec[0] but the null flag is left uncleared.

partition_range.result:
  Results block for bug #17894
partition_range.test:
  Test block for bug #17894
partition_list.result:
  Results block for bug #17173
partition_list.test:
  Test block for bug #17173
opt_range.cc:
  call set_notnull to clear any null flag that may have been set