into hundin.mysql.fi:/home/heikki/mysql-4.0

  Make the drop InnoDB database operation aware of the setting FOREIGN_KEY_CHECKS=0; DROP DATABASE seems to work ok anyway, but that is because MySQL first calls DROP TABLE for each table which has an .frm file

into mysql.com:/home/my/mysql-4.0

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

Always use all LOAD DATA options in replication.
Fixed problem in mysqlbinlog where LOAD DATA options could be overwritten.

into mysql.com:/space/my/mysql-4.0

into eagle.mysql.r18.ru:/home/vva/work/BUG_2898/mysql-4.0

into eagle.mysql.r18.ru:/home/vva/work/BUG_2898/mysql-4.0

 - Tagged ChangeSet@1.1733 as mysql-4.0.18

   on libstdc++ and exceptions

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

into mysql.com:/bk/mysql-4.0

into mysql.com:/home/my/mysql-4.0

  Allow always DROPping of a table which is only referenced by FOREIGN KEY constraints from the same table
Many files:
  Do not let REPLACE to perform internally an UPDATE if the table is referenced by a FOREIGN KEY: the manual says that REPLACE must resolve a duplicate key error semantically with DELETE(s) + INSERT, and not by an UPDATE; the internal update caused foreign key checks and cascaded operations to behave in a semantically wrong way

into mysql.com:/bk/mysql-4.0

  Fix crash in InnoDB RENAME TABLE if 'databasename/tablename' is shorter than 5 characters (Bug #2689); reported by Sergey Petrunia

alter table rename a bit more efficient in case of
lower_case_table_names.

  Fix bug #2167: generate foreign key id's locally for each table, in the form databasename/tablename_ibfk_number; if the user gives the constraint name explicitly remember it; these changes should ensure that foreign key id's in a slave are the same as in the master, and DROP FOREIGN KEY does not break replication
sync0sync.c:
  UNIV_SYNC_DEBUG caused assertion in the creation of the doublewrite buffer, if we do not allow thousands of latches per thread

  If AUTOCOMMIT=1, then we do not need to make a plain SELECT set shared locks even on the SERIALIZABLE isolation level, because we know the transaction is read-only: a read-only transaction can always be performed on the REPEATABLE READ level, and that does not endanger the serializability

into mysql.com:/home/kostja/mysql/mysql-4.0-merge

   1.5 to fix BUG#202 (update config.guess & co for MIPS architecture)

into mysql.com:/space/my/mysql-4.0

   so it gets picked up by "make dist" and updated init_file test accordingly.

into eagle.mysql.r18.ru:/home/vva/work/BUG_2526/mysql-4.0

  Added a comment for already pushed bug fix