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.

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

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0

+ adopted signal to be as close as possible to 5.1...

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

In the Windows build files, the "Max nt" configuration for some reason
had the mysql_client_test project disabled. Enable it.

Improved definition of mysys configuration for -nt builds.

Make sure for the mysys project that __NT__ is defined in *nt solution
configurations (but not in other configurations).

into  mysql.com:/home/alexi/bugs/mysql-5.0-19208

 and BUG#19208 "Test 'rpl000017' hangs on Windows".
 Both bugs are caused by attempting to delete an opened
 file and to create immediatedly a new one with the same
 name. On Windows it can be supported only on NT-platforms
 (by using FILE_SHARE_DELETE mode and with renaming the
 file before deletion). Because deleting not-closed files
 is not supported on all platforms (e.g. Win 98|ME) this
 is to be considered harmful and should be eliminated by
 a "code redesign".

- correction of previous patch

- make sure to allocate just enough pages in the fragments by using the actual
  row count from the backup, to avoid over allocation of pages to fragments, and
  thus avoid the bug

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

Sometimes the helper connection (that is watching for the main connection
to time out) would itself time out first, causing the test to fail.

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main

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

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main

into  mysql.com:/usr/home/ram/work/mysql-5.0

  Additional fix for #16377 for bigendian platforms
sql_select.cc, select.result, select.test:
  After merge fix

into moonbone.local:/work/tmp_merge-5.0-opt-mysql

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

  Added test case for bug#18759 Incorrect string to numeric conversion.  
select.test:
  Added test case for bug#18759 Incorrect string to numeric conversion.
item_cmpfunc.cc:
  Cleanup after fix for bug#18360 removal

into  mysql.com:/home/emurphy/mysql-5.0-heikki

Fixes bug#17264, for alter table on win32 for successfull operation completion
it is used TL_WRITE(=10) lock instead of TL_WRITE_ALLOW_READ(=6), however here
in innodb handler TL_WRTIE is lifted to TL_WRITE_ALLOW_WRITE, which causes
race condition when several clients do alter table simultaneously.

into  poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main