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

the bug with 3.23.
ChangeSet@1.1416.113.1, 2003-03-22 15:22:59+01:00, guilhem@mysql.com
  Fix for #178  Replicating INSERT VALUES(USER()) crashes (SEGV) the slave
      Now it does not SEGV, but USER() is still badly replicated
      (it is replicated to ""), which is a lower priority bug.

  Backport from 4.0 of the btr0sea.c latch hang fix

into mashka.mysql.fi:/home/my/mysql-3.23

was used with NULL value on NOT NULL column. (Bug #479)

into eagle.mysql.r18.ru:/home/vva/work/BUG_479_/mysql-3.23

repository (incredible that I forgot to push, but why not).
So unfortunately the bugfix missed 3.23.57 and will be in .58 :(
Instead of looking like working (bug #198), replication between
a 3.23 slave and 4.0 master should frankly stop. Here we detect
4.0 masters in the 3.23 slave code when we see a strange Rotate
event, and in that case we print an error and stop.
4.0.13 and older masters will be "often" caught (see the patch); 4.0.14
and newer masters will always be immediately caught.

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

  Backport the clust rec bug fix from 4.0

into mysql.com:/home/mysql_src/mysql-3.23

as the already-stored timestamp. Now 'created' is used only to know if
this is a first binlog or not. And we may re-use the superfluous bytes
in 5.0 when we need room.

  Prevent on Windows starting of two mysqld instances on SAME InnoDB files: that could cause severe database corruption

  Fix a bug: a race condition could cause that the first B-tree page splits would get a corrupt page directory, whic often results in the assertion in page_dir_find_slot(); found with a test of 3000 startups/shutdowns; it is not clear that this would have caused any corruption which users have reported

Otherwise, we'll get questions from users about this curious 1970.

Fix for bug 254 : the first Start_log_event after server startup will
have created=now(), whereas the next ones (FLUSH LOGS, auto rotation)
will have created=0. Before this, it was always now().
This way, slaves >=4.0.14 will know when they must
drop stale temp tables or not. The next task is now modify 4.0.14 to
implement this.

into narttu.mysql.fi:/my/mysql-3.23

(Casused problems in GIS functions in 4.1)

  Prevent the InnoDB main thread from hogging CPU if a table lingers in the background drop queue (though it is essentially a bug if a table end up there at all)

into narttu.mysql.fi:/my/mysql-3.23

into mashka.mysql.fi:/home/my/mysql-3.23