into rurik.mysql.com:/home/igor/dev/mysql-4.1-0

BitKeeper/triggers/post-commit:
  Auto merged
sql/table.cc:
  Auto merged

  After revision of the fix for bug #7520.
table.cc:
  Revised the fix for bug #7520.
  Made it compliant with 5.0 code where the bug does not exist.


sql/table.cc:
  Revised the fix for bug #7520.
  Made it compliant with 5.0 code where the bug does not exist.
mysql-test/r/select.result:
  After revision of the fix for bug #7520.

into mysql.com:/M41/mysql-4.1

into mysql.com:/home/mydev/mysql-4.1-bug8306

Build-tools/Do-compile:
  Auto merged

into rurik.mysql.com:/home/igor/dev/mysql-4.1-0


BitKeeper/etc/logging_ok:
  auto-union
extra/replace.c:
  Auto merged

  Adjusted results of the test case for bug #7520 for 4.1.


mysql-test/r/select.result:
  Adjusted results of the test case for bug #7520 for 4.1.

into rurik.mysql.com:/home/igor/dev/mysql-4.0-0

into rurik.mysql.com:/home/igor/dev/mysql-4.1-0


BitKeeper/etc/logging_ok:
  auto-union
extra/replace.c:
  Auto merged
mysql-test/r/select.result:
  Auto merged
mysql-test/t/select.test:
  Auto merged
sql/table.cc:
  Auto merged

  Added a test case for bug #7520.
table.cc:
  Fixed bug #7520.
  The bug was caused by a wrong calculation of the field max_key_length for
  a TABLE structure when there was an index on a blob field.


sql/table.cc:
  Fixed bug #7520.
  The bug was caused by a wrong calculation of the field max_key_length for
  a TABLE structure when there was an index on a blob field.
mysql-test/t/select.test:
  Added a test case for bug #7520.
mysql-test/r/select.result:
  Added a test case for bug #7520.

BitKeeper/triggers/post-commit:
  Remove extra blank link

Set of fixes requested by Kent in IRC. Tested (except the windows changes since I am trusting Kent...). No windows compiles here folks...


VC++Files/tests/mysql_client_test.dsp:
  fix request by Kent
sql/item.cc:
  fix requested by kent

BitKeeper/etc/logging_ok:
  auto-union
extra/replace.c:
  Auto merged
BitKeeper/triggers/post-commit:
  Merge changes

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

binlog-do-db or binlog-ignore-db are in effect.   (In the future 5.1? 5.0? I think 
each statement should be verified against the filtering criteria based on the database
it *uses* and not the *current* one.  But, right now the *current* database is what 
counts according to the semantics of the manual.)


sql/log.cc:
  BUG#6749: If there is no current database, then nothing should be binlogged if
  binlog-do-db or binlog-ignore-db are in effect.   (In the future I think that each 
  statement should be verified against the filtering criteria based on the database
  it *uses* and not the *current* one.  But, right now the *current* database is what 
  counts according to the semantics of the manual.)

It was a thread stack overrun.
IA64 had its own stack size section already.
Enlarged its default stack size from 192K to 256K.

libmysql/libmysql.c:
  And now put it to the proper place and make it work (Bug#7990)
tests/mysql_client_test.c:
  Enable the test for bug#7990

reset mysql->net.last_error": the solution is to clear
MYSQL->net error before performing COM_CLOSE: if the call
succeeds, the connection is usable for other statements.
More comprehensive fix is to clear MYSQL->net for all
recoverable errors at the time they happen, it will be
implemented in 5.0 as it introduces incompatibility in behavior.


libmysql/libmysql.c:
  A simple fix for Bug#7990 "mysql_stmt_close doesn't reset 
  mysql->net.last_error"
tests/mysql_client_test.c:
  A test case for Bug#7990 " mysql_stmt_close doesn't reset 
  mysql->net.last_error"

it also works on file names with special characters.


Build-tools/Do-compile:
  Ever and again, some test creates a file name with special characters that need to be
  escaped when passed to the shell; as this is not done, 'system("rm -f ...");' fails
  on them, the old test tree is not deleted, and the build fails.
  Prevent this by changing to Perl 'unlink()' which does not need escaping.

libmysql/libmysql.c:
  Fix for bug#8330 "mysql_stmt_execute crashes": we need to bail out
  from mysql_stmt_execute if mysql->net is occupied with a result set of
  another statement. Otherwise on the next attempt to use net we get
  a crash, as it's freed in case of error.
tests/mysql_client_test.c:
  A test case for Bug#8330 "mysql_stmt_execute craches" (libmysql)

into mysql.com:/home/jimw/my/mysql-4.1-clean

into sanja.is.com.ua:/home/bell/mysql/bk/work-4.1


sql/item_cmpfunc.cc:
  Auto merged

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


sql/sql_select.cc:
  Auto merged

into mysql.com:/space/my/mysql-4.1-merge

- updated mysql-copyright-2 to properly convert this new header from GPL to commercial for the
  commercial distribution


Build-tools/mysql-copyright-2:
  - added functionality to replace a copyright header in .sql files, too (needed for updating
    scripts/fill_help_tables.sql in the commercial source distribution)
scripts/fill_help_tables.sh:
  - added copyright header on top of the fill_help_tables.sql file (BUG#5772)

into mysql.com:/home/jonas/src/mysql-4.1

Fix bug in bug fix in FastScheduler
  remove possibility of endless loop
  resulting in APZJobBuffer overflow due to statistics reporting


ndb/src/kernel/vm/FastScheduler.cpp:
  Fix bug in bug fix in FastScheduler
    remove possibility of endless loop
    resulting in APZJobBuffer overflow due to statistics reporting

mysql-test/r/heap_hash.result:
  Testcase for BUG#8371: wrong rec_per_key value for hash index on temporary table
mysql-test/t/heap_hash.test:
  Testcase for BUG#8371: wrong rec_per_key value for hash index on temporary table
sql/ha_heap.cc:
  Fix for BUG#8371: wrong rec_per_key value for hash index on temporary table:
  Don't assume that table->rec_per_key==NULL if table->tmp_table != NO_TMP_TABLE, 
  this is not true for tables created with "CREATE TEMPORARY TABLE" (while it holds
  for temporary tables created during query execution)
sql/sql_select.cc:
  Initialize rec_per_key for all keys in temporary table.

into mysql.com:/home/wax/mysql/mysql-4.1test2

into hundin.mysql.fi:/home/jan/mysql-4.1

Ensure that references in HAVING, ORDER BY or GROUP BY are calculated after fields in SELECT.
This will ensure that any reference to these has a valid value.
Generalized the code for split_sum_func()


BitKeeper/etc/ignore:
  added support-files/ndb-config-2-node.ini
mysql-test/r/group_by.result:
  More complicated test to assure that rand() is only calulated once
mysql-test/r/user_var.result:
  Back to old results :(  (ok but not perfect)
mysql-test/t/group_by.test:
  More complicated test to assure that rand() is only calulated once
sql/item.cc:
  Better bugfix for "HAVING when refering to RAND()"
  This will ensure that when refering to things like RAND() in HAVING through an alias we will not recalculate that rand() value in the HAVING part but use the value in the row
  Generalize split_sum_func()
sql/item.h:
  Better bugfix for "HAVING when refering to RAND()"
  T
sql/item_cmpfunc.cc:
  Better bugfix for "HAVING when refering to RAND()"
  Use generalized split_sum_func2() function
sql/item_func.cc:
  Better bugfix for "HAVING when refering to RAND()"
  Use generalized split_sum_func2() function
sql/item_row.cc:
  Better bugfix for "HAVING when refering to RAND()"
  Use generalized split_sum_func2() function
sql/item_strfunc.cc:
  Better bugfix for "HAVING when refering to RAND()"
  Use generalized split_sum_func2() function
sql/sql_list.h:
  Add functions to concatenate lists
sql/sql_select.cc:
  Better bugfix for "HAVING when refering to RAND()"
  Ensure that references in HAVING, ORDER BY or GROUP BY are calculated after fields in SELECT.
  This will ensure that any reference to these has a valid value.

single table DELETE...SELECT clauses when innobase_locks_unsafe_for_binlog
is used and isolation level of the transaction is not serializable. 
InnoDB uses consistent read in these cases for a selected table.
Backported from 5.0.x.


sql/ha_innodb.cc:
  Relaxed locking in INSERT...SELECT, single table UPDATE...SELECT and 
  single table DELETE...SELECT clauses when innobase_locks_unsafe_for_binlog
  is used and isolation level of the transaction is not serializable. 
  InnoDB uses consistent read in these cases for a selected table.

into mysql.com:/usr/home/ram/work/4.0