into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.1-maint

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/bug20836/my51-bug20836

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/bug20836/my50-bug20836

- Comment Cleanup.

error message in the logs before shutting down the server

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-maint

into  example.com:/work/bug22369-v2/my51

into  naruto.:C:/cpp/mysql-5.1-maint

disables binlog.

into  example.com:/work/bug22369-v2/my51

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

Close any statements that might be open before program exit
Close any statments that might be open when calling "disable_ps_protocol"

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  neptunus.(none):/home/msvensson/mysql/mysql-4.1-maint

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/bug20836/my51-bug20836

into  neptunus.(none):/home/msvensson/mysql/mysql-5.1

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.0-maint

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/mysql-5.1-maint

into  example.com:/work/bug22369-v2/my51

into  rolltop.ignatz42.dyndns.org:/mnt/storeage/bug17951/my51-bug17951

with other alterations causes lost tables

Using RENAME clause combined with other clauses of ALTER TABLE led to
data loss (the data was there but not accessible). This could happen if the
changes do not change the table much. Adding and droppping of fields and
indices was safe. Renaming a column with MODIFY or CHANGE was unsafe operation,
if the actual column didn't change (changing from int to int, which is a noop)
  
Depending on the storage engine (SE) the behavior is different:
1)MyISAM/MEMORY - the ALTER TABLE statement completes
  without any error but next SELECT against the new table fails.
2)InnoDB (and every other transactional table) - The ALTER TABLE statement
  fails. There are the the following files in the db dir -
  `new_table_name.frm` and a temporary table's frm. If the SE is file
  based, then the data and index files will be present but with the old
  names. What happens is that for InnoDB the table is not renamed in the
  internal DDIC.

Fixed by adding additional call to mysql_rename_table() method, which should
not include FRM file rename, because it has been already done during file
names juggling.

into  dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.1

into  dl145s.mysql.com:/data0/bk/team_tree_merge/MERGE2/mysql-5.0

 - Add CR_CONN_HOST_ERROR to list of errorcode that trigger another connection
   attempt in mysqltest

into  naruto.:C:/cpp/mysql-5.1-maint

  fixed a valgrind problem

   fixed a valgrind warning
type_varchar.test:
  fixed a valgrind warning

into  mysql.com:/windows/Linux_space/MySQL/mysql-5.1

  Disabled abi_check, as it was before merge

into  mysql.com:/home/kent/bk/mysql-5.1-build

  If --srcdir and --windows is given, check if error message file
  is in source or build tree (bug#24557)
Makefile.am:
  Cleaned up "ali_check" target, to satisfy "distcleancheck" (bug#24557)
mysql_install_db.sh:
  Added --srcdir=DIR option, used from top Makefile.am in dist-hook
  target, to find "fill_help_tables.sql" in VPATH build (bug#24557)
Makefile.am:
  Work around problem with "distcleancheck", "sql_yacc.cc" might be in both
  the source and build tree.
  Call "mysql_install_db" with new option --srcdir, to enable the script
  to find all that is needed, if source and build directory is not the same
  (bug#24557)

into  weblab.(none):/home/marcsql/TREE/mysql-5.1-maint-24736