VC++Files/InstallShield/4.0.XX-classic/File Groups/Clients and Tools.fgl:
  Add myisam_ftdump to client files
VC++Files/InstallShield/4.0.XX-classic/File Groups/Development.fgl:
  Add mysql_fix_privilege_tables.sql
VC++Files/InstallShield/4.0.XX-classic/File Groups/Servers.fgl:
  Add README.txt
VC++Files/InstallShield/4.0.XX-gpl/File Groups/Clients and Tools.fgl:
  Add myisam_ftdump to client files
VC++Files/InstallShield/4.0.XX-gpl/File Groups/Development.fgl:
  Add mysql_fix_privilege_tables.sql
VC++Files/InstallShield/4.0.XX-gpl/File Groups/Servers.fgl:
  Add README.txt
VC++Files/InstallShield/4.0.XX-pro/File Groups/Clients and Tools.fgl:
  Add myisam_ftdump to client files
VC++Files/InstallShield/4.0.XX-pro/File Groups/Development.fgl:
  Add mysql_fix_privilege_tables.sql
VC++Files/InstallShield/4.0.XX-pro/File Groups/Servers.fgl:
  Add README.txt
VC++Files/mysql.dsw:
  Add myisam_ftdump
VC++Files/mysys/mysys.dsp:
  Fix defines
VC++Files/sql/mysqld.dsp:
  Fix defines, etc

into mysql.com:/bk/mysql-4.0

   (which is "darwin7" now) - "-DHAVE_BROKEN_REALPATH" is not required
   anymore, too, as realpath() is thread-safe on Panther now.
   (Thanks to Al Begley from Apple for the info)

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


sql/ha_innodb.cc:
  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

sql/share/english/errmsg.txt:
  Added note to ensure that no one adds new error message to 4.0.
  This is important as it causes too many problems with test suite in 4.1
sql/sql_load.cc:
  Removed wrong comment.

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


configure.in:
  Auto merged

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.


client/mysqlbinlog.cc:
  Ensure that we don't call init_dynamic_array() before my_init() has been done
configure.in:
  Always use libtool with "--preserve-dup-deps" to prevent link problems with g++
mysql-test/r/mysqlbinlog.result:
  new results
mysql-test/r/range.result:
  new results
mysql-test/t/range.test:
  add missing DROP TABLE
sql/log_event.cc:
  Always use all LOAD DATA options. This is needed to handle commands of type "FIELDS TERMINATED BY ''"
  Allocate memory for Create_file_log_event options as these may be overwritten in mysqlbinlog
sql/log_event.h:
  Free buffer

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

mysql-test/r/select_found.result:
  added new tests for bugs with range optimization (bugs #2448 and #2698)
mysql-test/t/select_found.test:
  added new tests for bugs with range optimization (bugs #2448 and #2698)

 - Tagged ChangeSet@1.1733 as mysql-4.0.18


configure.in:
   - bumped up version number from 4.0.18 -> 4.0.19

support-files/mysql.spec.sh:
   - Replaced obsolete "Copyright" field with "License"

   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

client/mysqlbinlog.cc:
  Ensure that errors are returned to upper levels instead of just doing 'exit/die' in sub function.
sql/handler.h:
  Indentation cleanup
sql/sql_insert.cc:
  Indentation cleanup

  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


sql/ha_innodb.cc:
  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
sql/sql_insert.cc:
  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
sql/ha_innodb.h:
  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
sql/handler.h:
  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
innobase/dict/dict0dict.c:
  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
innobase/include/dict0dict.h:
  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
innobase/row/row0mysql.c:
  Allow always DROPping of a table which is only referenced by FOREIGN KEY constraints from the same table

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


innobase/row/row0mysql.c:
  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


innobase/dict/dict0crea.c:
  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
innobase/dict/dict0dict.c:
  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
innobase/include/dict0crea.h:
  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
innobase/include/dict0dict.h:
  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
innobase/include/ut0mem.h:
  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
innobase/row/row0mysql.c:
  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
innobase/sync/sync0sync.c:
  UNIV_SYNC_DEBUG caused assertion in the creation of the doublewrite buffer, if we do not allow thousands of latches per thread
innobase/ut/ut0mem.c:
  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

  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


sql/ha_innodb.cc:
  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

client/mysqlbinlog.cc:
  fixed bug #1378 "mysqlbinlog for remote host is broken"
  by using shared part of code for local and remote variant 
  (function process_event)
mysql-test/r/mysqlbinlog.result:
  fixed results for remote variant 
  (they are the same as for local now)
mysql-test/t/mysqlbinlog.test:
  discarded note 'V. Vagin should ...' 
  because V.Vagin done
sql/log_event.cc:
  added special local_fname flag to Load_log_event for 
  using in Load_log_event::check_fname_outside_temp_buf 
  instead of ugly condition
sql/log_event.h:
  added special local_fname flag to Load_log_event for 
  using in Load_log_event::check_fname_outside_temp_buf 
  instead of ugly condition

BitKeeper/etc/ignore:
  auto-union
BitKeeper/etc/logging_ok:
  auto-union
mysql-test/r/func_math.result:
  Auto merged
mysql-test/t/func_math.test:
  Auto merged
sql/item_func.cc:
  Auto merged

BitKeeper/etc/logging_ok:
  Logging to logging@openlogging.org accepted
mysql-test/r/alter_table.result:
  Fix for bug #2628: test result fixed
mysql-test/t/alter_table.test:
  Fix for bug #2628: test case added
sql/sql_table.cc:
  Fix for bug #2628:
  We need to take into account database name when checking if source and 
  destination table names are equal.
  Note, that after merge to 4.0 we also need to check for 
  lower_case_table_names.

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


config.guess:
   - upplied diffs from libtool 1.5
config.sub:
   - upplied diffs from libtool 1.5
ltmain.sh:
   - upplied diffs from libtool 1.5

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