Would you believe that I wrote all of this on a Mac? I just happen to be not using HFS for the partition I did this work on. Oops :)

into avenger.(none):/export/brian/mysql/acinclude-5.0

into sanja.is.com.ua:/home/bell/mysql/bk/work-qc-4.1

into sanja.is.com.ua:/home/bell/mysql/bk/work-global-4.1

into mysql.com:/home/jonas/src/mysql-4.1

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

into mysql.com:/home/jonas/src/mysql-4.1

1 if the return type is int or int_fast8_t.  The test case that showed
this problem is rpl000001 and the tested version was MySQL 5.0.2.  The
compiler with the problem is GCC 3.0.4 runing on "Linux bitch 2.4.18
#2 Thu Apr 11 14:37:17 EDT 2002 sparc64 unknown".

By changing the return type to bool the problem disappear.  (Another
way to make the problem disappear is to simply print the returned
value with printf("%d",?).  The printed returned value is always 0 in
the test cases I have run.)  This is only a partial solution to the
problem, since someone could later change the return type of the
function back to int or some other type that does not work.

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

into mysql.com:/home/jonas/src/mysql-4.1

    Bug #6284 - report truncation warnings in INSERT ... SELECT only for "INSERT" part
sql/sql_insert.cc
    Bug #6284 - report truncation warnings in INSERT ... SELECT only for "INSERT" part

into mysql.com:/space/pekka/ndb/version/my41

    decimal_round(d, -N) bug fixed

    fixed broken d2ll
    added checks for correct test results

into mysql.com:/home/wax/mysql/mysql-4.1testtemp

into mysql.com:/home/jonas/src/mysql-4.1

into mysql.com:/space/bk/b6391-mysql-4.1

  CREATE DATABASE statement used the current database instead of the
  database created when checking conditions for replication.
  CREATE/DROP/ALTER DATABASE statements are now replicated based on
  the manipulated database.

insertion of new records partially failed. It would get logged because of the
logic to log a partially-failed 'INSERT ... SELECT' (which can't be rolled back
in non-transactional tables), but 'CREATE TABLE ... SELECT' is always rolled
back on failure, even for non-transactional tables. (Bug #6682)
(Original fix reimplemented after review by Serg and Guilhem.)

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

Making FLUSH TABLES WITH READ LOCK killable while it's waiting for running commits to finish. Normally this step is not long but it's still nice to be killable
(especially in case of bug like BUG#6732 "FLUSH TABLES WITH READ LOCK + COMMIT makes next FLUSH...LOCK hang forever").