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

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

hp_test2 now works again
Fixed wrong cast, which caused problems with gcc 4.0 and floats in prepared statements (Bug #19694)

into  mysql.com:/mnt/storeage/mysql-4.1_bug19298

into  poseidon.ndb.mysql.com:/home/tomas/mysql-4.1-main

into  mysql.com:/home/stewart/Documents/MySQL/4.1/main

into  mysql.com:/home/stewart/Documents/MySQL/4.1/merge

change default minimum to 3

bug is *very* timing dependent, unable to reproduce here, but theoretically possible.

Produce a warning if DATA/INDEX DIRECTORY is specified in
ALTER TABLE statement.

Ignoring of these options is documented in the symbolic links
section of the manual.

Dec. 31st, 9999 is still a valid date, only starting with Jan 1st 10000 things become invalid (Bug #12356)

into mysql.com:/home/hf/work/mysql-4.1.clean

into mysql.com:/Users/kent/mysql/bk/mysql-4.1-new

  For compatibility, don't use {..,..} in pattern matching
make_binary_distribution.sh:
  Added .dylib and .sl as shared library extensions

into mysql.com:/home/hf/work/mysql-4.1.clean

into mysql.com:/home/hf/work/mysql-4.1.clean

  An UNIQUE KEY consisting of NOT NULL columns
  was displayed as PRIMARY KEY in "DESC t1".
  According to the code, that was intentional
  behaviour for some reasons unknown to me.
  This code was written before bitkeeper time,
  so I cannot check who and why made this.
  After discussing on dev-public, a decision
  was made to remove this code

  Disable the simplistic auto dependency scan for test/bench (bug#20078)

The AsBinary function returns VARCHAR data type with binary collation.
It can cause problem for clients that treat that kind of data as
different from BLOB type.
So now AsBinary returns BLOB.

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

This bug in Field_string::cmp resulted in a wrong comparison 
with keys in partial indexes over multi-byte character fields.
Given field a is declared as a varchar(16) collate utf8_unicode_ci
INDEX(a(4)) gives us an example of such an index.
  
Wrong key comparisons could lead to wrong result sets if 
the selected query execution plan used a range scan by 
a partial index over a utf8 character field.
This also caused wrong results in many other cases.

into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1

into  may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-4.1

            functions in queries

Using MAX()/MIN() on table with disabled indexes (by ALTER TABLE)
results in error 124 (wrong index) from storage engine.

The problem was that optimizer use disabled index to optimize
MAX()/MIN(). Normally it must skip disabled index and perform
table scan.

This patch skips disabled indexes for min/max optimization.

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

  Added test case for bug#18759 Incorrect string to numeric conversion.  
select.test:
  Added test case for bug#18759 Incorrect string to numeric conversion.
item_cmpfunc.cc:
  Cleanup after fix for bug#18360 removal

into  mysql.com:/usr/home/ram/work/mysql-4.1

into  mysql.com:/usr/home/ram/work/mysql-4.1

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

into moonbone.local:/work/tmp_merge-4.1-opt-mysql

  Reverted fix for bug#18360

there was two problems about charsets in embedded server
1. mysys/charset.c - defined there default_charset_info variable is
modified by both server and client code (particularly when
--default-charset option is handled)
In embedded server we get two codelines modifying one variable.
I created separate default_client_charset_info for client code

2. mysql->charset and mysql->options.charset initialization isn't
properly done for embedded server - necessary calls added

into  mysql.com:/home/kgeorge/mysql/4.1/B9676

              tables
Currently in INSERT ... SELECT ... LIMIT ... the compiler uses a 
temporary table to store the results of SELECT ... LIMIT .. and then
uses that table as a source for INSERT. The problem is that in some cases
it actually skips the LIMIT clause in doing that and materializes the 
whole SELECT result set regardless of the LIMIT.
This fix is limiting the process of filling up the temp table with only 
that much rows that will be actually used by propagating the LIMIT value.

into  mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge

into  may.pils.ru:/home/svoj/devel/mysql/BUG18036/mysql-4.1