into mysql.com:/home/dlenev/src/mysql-4.0-bg7297

the Epoch". (With after review fixes).

  Fix the previous bug fix: dropping a table with FOREIGN KEY checks running on it caused a cascade of failed drops while the foreign key check was waiting for a lock

  Fix bug: if we dropped a table where an INSERT was waiting for a lock to check a FOREIGN KEY constraint, then an assertion would fail in lock_reset_all_on_table(), since that operation assumes no waiting locks on the table or its records
row0mysql.c:
  Fix bug: InnoDB failed to drop a table in the background drop queue if the table was referenced by a foreign key constraint

into sinisa.nasamreza.org:/mnt/work/mysql-4.0

to behave well on 5.0 tables (well now you can't use tables from 4.1
and 5.0 with 4.0 because former use utf8, but still it is nice to have
similar code in acl_init() and replace_user_table()).
This also will make such GRANTs working in 5.0 (they are broken now).

  If AUTOCOMMIT=1, do not acquire an InnoDB table lock in LOCK TABLES; this makes porting of old MyISAM applications to InnoDB easier, since in that mode InnoDB table locks caused deadlocks very easily

  Put back accidentally removed undef and remove a debug def

  Fix InnoDB bug: on HP-UX, with a 32-bit binary, InnoDB was only able to read or write <= 2 GB files; the reason was that InnoDB treated the return value of lseek() as a 32-bit integer; lseek was used on HP-UX-11 as a replacement for pread() and pwrite() because HAVE_BROKEN_PREAD was defined on that platform

  Increment from 4.0.23 to 4.0.24

into ltantony.rdg.cyberkinetica.homeunix.net:/usr/home/antony/work/bug7391.4

  Add in missing privilege checks. 
  Tests for the privileges.

into mysql.com:/M40/mysql-4.0

even with zero month and day" aka "Date decoding trouble"

Two digit year should be interpreted correctly as year in 20th or 21st
century even with zero month and day. Only exception should be zero date
'00-00-00' or '00-00-00 00:00:00'.

  dict_load_table(): detect the new table format of MySQL 5.0.3

into mysql.com:/dbdata/psergey/mysql-4.0-bug6976

In Item_ref::Item_ref set maybe_null (and other fields fix_fields sets) to be the 
same as in (*ref), because Item_ref::fix_fields() will not be called.  Previously 
maybe_null was 0 always and this produced a bogus state where 
maybe_null==0 && is_null() == true 
which broke evaluation for some upper-level Items, like AND and OR.

  Call mark_as_null_row in join_read_const and join_read_system.

into hundin.mysql.fi:/home/marko/k/mysql-4.0

  Fix for the 0xA0 character problem in the InnoDB FOREIGN KEY parser: if my_isspace() treats 0xA0 as space, then let InnoDB do the same; this might break some multi-byte charset id's, though for big5, ujis, sjis this seems not to change the current behavior (I checked the tables in /share/charsets); this fix must NOT be merged to 4.1 because in 4.1 everything is in UTF-8

  srv_printf_innodb_monitor(): Removed extraneous rewind() call.
  The caller of this function calls rewind() if necessary.
  In this way, we avoid rewind()ing stderr in
  srv_lock_timeout_and_monitor_thread().

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

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.)

two-line fix for BUG#6732 "FLUSH TABLES WITH READ LOCK + COMMIT makes next FLUSH...LOCK hang forever"
(originally reported as "second run of innobackup hangs forever and can even hang server").
Plus testcase for the bugfix and comments about global read locks.

  srv_lock_timeout_and_monitor_thread(): write to srv_monitor_file
  only if --innodb_status_file=1

(Cleanups and better bug fixes)

into mysql.com:/home/timka/mysql/src/4.0-master

into mysql.com:/space/bk/b6148-mysql-4.0