into serg.mylan:/usr/home/serg/Abk/mysql-5.0

into snake-hub.snake.net:/src/extern/MySQL/bk/mysql-5.0

into serg.mylan:/usr/home/serg/Abk/mysql-5.0

into mysql.com:/home/mysql_src/mysql-5.0-xa

pushed some minutes ago)

into mysql.com:/home/timka/mysql/src/5.0-bug-8576

This fix addresses a bug of the HPUX C++ compiler, in the way it uses registers.
As result, the last comparison of the variable 'result' failed, and next_prefix()
looped forever.

into mysql.com:/home/bk/b8412-mysql-4.0

into serg.mylan:/usr/home/serg/Abk/mysql-5.0

auto-end-rollback in case crashed binlog) which cannot hurt.

  cast sql_mode to ulonglong before int8store, otherwise the implementation of int8store
  based on >> complains that we do 32-bit var >> 32 which is undefined according to C standard.
  (compiler warning appeared on SGI Irix)

into mysql.com:/home/mysql_src/mysql-5.0-xa

correct end_log_pos for Xid_log_event

into ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0

into gluh.mysql.r18.ru:/home/gluh/MySQL-MERGE/mysql-5.0

into mysql.com:/home/mysql_src/mysql-4.1-clean

1) If my.cnf is found in datadir and basedir, give a warning and use the
   one in basedir.
2) If my.cnf is found in datadir, use it, but give a warning.
3) No warning if my.cnf is in basedir.

start_waiting_global_read_lock() should wake up all those who are waiting
for protect_against_global_read_lock to go down to 0: those registered in waiting_for_read_lock
AND those registered in global_read_lock_blocks_commit.

into gluh.mysql.r18.ru:/home/gluh/MySQL-MERGE/mysql-5.0

into mysql.com:/usr/home/bar/mysql-5.0.fresh

into mysql.com:/home/timka/mysql/src/5.0-bug-8576

new tests

into ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0

into mysql.com:/home/timka/mysql/src/5.0-bug-8576

into gluh.mysql.r18.ru:/home/gluh/MySQL/mysql-5.0

into mysql.com:/usr/home/bar/mysql-4.1

  Activate Unicode collations in Windows version.

        bug #7215: information_schema: columns are longtext instead of varchar

The problem was in different representations of double variables depending on
platform/compiler/compile options. In some cases double variables are represented by
64 bits (while in memory), or by 80 bits (while in FPU register). As a result equal
values are not considered "==". As many sources point out,  doubles should not be
compared by '==' for this reason. This fix subtracts the scaled minimal double
value X such that 1 + X != 1, to ensure that the inequality holds in any case.

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