into  pippilotta.erinye.com:/shared/home/df/mysql/build/mysql-5.0-build

into  trift2.:/MySQL/M50/push-5.0

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/50

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/50

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/50

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/50

into  ramayana.hindu.god:/home/tsmith/m/bk/maint/41

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

Fixed the build failure on Windows. It does not have trunc() defined in math.h, so we should not use it code.

into  polly.(none):/home/kaa/src/maint/mysql-5.0-maint

numbers into char fields" and bug #12860 "Difference in zero padding of
exponent between Unix and Windows"

Rewrote the code that determines what 'precision' argument should be
passed to sprintf() to fit the string representation of the input number
into the field.
We get finer control over conversion by pre-calculating the exponent, so
we are able to determine which conversion format, 'e' or 'f', will be
used by sprintf().
We also remove the leading zero from the exponent on Windows to make it
compatible with the sprintf() output on other platforms.

into  four.local.lan:/work/trees/mysql-5.0-build-src-clean

into  four.local.lan:/work/trees/mysql-5.0-build-src-clean

into  four.local.lan:/work/trees/mysql-4.1-build-src-clean

into  four.local.lan:/work/merge/mysql-5.0-dev

   Bug#31030 rpl000015.test fails if $MYSQL_TCP_PORT != 3306
Note:
  This bug does not occur in MySQL 5.0 and up, because
  ChangeSet 1.2328.2.1 2006/11/27 for MySQL 5.0 prevents this.
  The 5.0 fix uses the environment variable DEFAULT_MASTER_PORT
  which is set by mysql-test-run.pl.
  mysql-test-run.pl in 4.1 does not set this variable.
  There are two alternatives:
  1) Backport the 5.0 fix for this test including modifications
     to mysql-test-run.pl and mysql-test-run-shell.
     This is a not acceptable impact on an old MySQL version.
  2) Fix the problem different than in 5.0 like in the current
     ChangeSet + do not apply these changes when upmerging to 5.0

into  mysql.com:/home/kent/bk/mac-os-x-universal/mysql-5.0-build

  Added 64 bit Mac OS X hard coded settings, for universal binaries

into  mysql.com:/home/kent/bk/mac-os-x-universal/mysql-5.0-build

into  mysql.com:/home/kent/bk/mac-os-x-universal/mysql-5.0-build

  Added 64 bit Mac OS X hard coded settings, for universal binaries

into  lambda.hsd1.co.comcast.net.:/home/malff/TREE/mysql-5.0-rt-merge

into  mysql.com:/Users/davi/mysql/mysql-5.0-runtime

Kill of a CREATE TABLE source_table LIKE statement waiting for a
name-lock on the source table causes a bad lock interaction.

The mysql_create_like_table() has a bug that if the connection is
killed while waiting for the name-lock on the source table, it will
jump to the wrong error path and try to unlock the source table and
LOCK_open, but both weren't locked.

The solution is to simple return when the name lock request is killed,
it's safe to do so because no lock was acquired and no cleanup is needed.

Original bug report also contains description of other problems
related to this scenario but they either already fixed in 5.1 or
will be addressed separately (see bug report for details).

Disabled test case.

into  stella.local:/home2/mydev/mysql-5.0-axmrg

into  stella.local:/home2/mydev/mysql-5.0-axmrg

Disabled the test case.

into  mysql.com:/home/ram/work/b30495/b30495.5.0