into  gbichot3.local:/home/mysql_src/mysql-5.1

Fixing typo and potential memory problem.
Reducing number of concurrent mysqlslap threads since tests fail
in pushbuild due to too many threads.

Previous patch didn't work: moving variable settings inside critical region.

into  romeo.(none):/home/bk/b20821-mysql-5.1-new-rpl

in pushbuild on Replication/Backup team tree.

into  romeo.(none):/home/bkroot/mysql-5.1-new-rpl

into  eucla.lemis.com:/home/MySQL/5.1-Bug-20850

  BUG#20850: Assert during slave shutdown in many rpl_* tests.
  This was caused by a race condition at the end of handle_slave_io
  which under some circumstances allowed the cleanup to proceed before
  the thread had completed.

  Tidy up white space.

into  gbichot3.local:/home/mysql_src/mysql-5.0

into  gbichot3.local:/home/mysql_src/mysql-5.0

a too large value": the bug was that if MySQL generated a value for an
auto_increment column, based on auto_increment_* variables, and this value
was bigger than the column's max possible value, then that max possible
value was inserted (after issuing a warning). But this didn't honour
auto_increment_* variables (and so could cause conflicts in a master-master
replication where one master is supposed to generated only even numbers,
and the other only odd numbers), so now we "round down" this max possible
value to honour auto_increment_* variables, before inserting it.

into  mysql.com:/home/bk/b20821-mysql-5.1-new-rpl

Reverting to old behaviour of writing the query before all rows
have been written.

auto_increment breaks binlog":
if slave's table had a higher auto_increment counter than master's (even
though all rows of the two tables were identical), then in some cases,
REPLACE and INSERT ON DUPLICATE KEY UPDATE failed to replicate
statement-based (it inserted different values on slave from on master).
write_record() contained a "thd->next_insert_id=0" to force an adjustment
of thd->next_insert_id after the update or replacement. But it is this
assigment introduced indeterminism of the statement on the slave, thus
the bug. For ON DUPLICATE, we replace that assignment by a call to
handler::adjust_next_insert_id_after_explicit_value() which is deterministic
(does not depend on slave table's autoinc counter). For REPLACE, this
assignment can simply be removed (as REPLACE can't insert a number larger
than thd->next_insert_id).
We also move a too early restore_auto_increment() down to when we really know
that we can restore the value.

into  mysql.com:/users/lthalmann/bkroot/mysql-5.0-rpl

 Disabling 'rpl_openssl'.

 Enabling rpl_openssl.test for Windows to check that
 currently it still hangs (because I can't reproduce
 this on my machine).

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.1-merge

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge

into  dator5.(none):/home/pappa/bug17138

into  dator5.(none):/home/pappa/bug17138

into  dator5.(none):/home/pappa/bug20583

into  dator5.(none):/home/pappa/bug17138

Last round of review fixes

into moonbone.local:/work/merge-5.1

into  mysql.com:/data0/knielsen/tmp-5.1

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

binary disctribution for Falcon.

into moonbone.local:/work/merge-5.1

go from 623 seconds to 11 seconds on AMD64.
This is because we have no native atomic implementation on AMD64, 
so the rwlock-based implementation is used, which is  a bit slow.  
It will be probably be optimized for AMD64 quite soon, but for now 
this test case will do fewer iterations.

into  mysql.com:/home/cps/mysql/trees/5.1-team