This patch allows to configure MyISAM for 128 indexes per table.
The main problem is the key_map, wich is implemented as an ulonglong.
To get rid of the limit and keep the efficient and flexible
implementation, the highest bit is now used for all upper keys.
This means that the lower keys can be disabled and enabled 
individually as usual and the high keys can only be disabled and
enabled as a block. That way the existing test suite is still
applicable, while more keys work, though slightly less efficient.
To really get more than 64 keys, some defines need to be changed.
Another patch will address this.

  fixed BLOB, TEXT(wrong maximum length), BIT and integer types(wrong numeric_precision value)

into mysql.com:/home/gluh/MySQL/Merge/5.0

   changed 'SHOW PROCEDURE' behavoiur to be like INFORMATION_SCHEMA.routines

list.

into  mysql.com:/Users/emurphy/src/work/mysql-5.0-bug11567

into  radha.local:/Users/patg/mysql-build/mysql-5.0

as well as changes to the test.

into  mysql.com:/Users/emurphy/src/work/mysql-5.0-bug11567

into  mysql.com:/home/kostja/mysql/mysql-5.0-merge

get_defaults_file() -> get_defaults_options()

into  mishka.local:/home/my/mysql-5.0

into moonbone.local:/work/mysql-5.0-bug-11482

into moonbone.local:/work/mysql-5.0-bug-11482

into lmy002.wdf.sap.corp:/home/georg/work/mysql/prod/mysql-5.0

  Changed test case comment to be more meaningful

  than in previous 4.1.x

Wrongly applied optimization were adding NOT NULL constraint which results in
rejecting valid rows and reduced result set.

The problem was that add_notnull_conds() while checking subquery were adding
NOT NULL constraint to left joined table, to which, normally, optimization 
don't have to be applied.

into production.mysql.com:/nfstmp1/guilhem/mysql-4.1-prod

 LOCK_thread_count)" and for BUG#12004 "SHOW BINARY LOGS reports 0
for the size of all binlogs but the current one".
There are a lot of 4.1->5.0 unmerged changes (hardest are in the optimizer), can't merge; still pushing in 4.1 because my changes 
are very small. Feel free to ask me if you have problems merging them.

Changed defaults option --instance to --defaults-group-suffix
Changed option handling to allow --defaults-file, --defaults-extra-file and --defaults-group-suffix to be given in any order
Changed MYSQL_INSTANCE to MYSQL_GROUP_SUFFIX
mysql_print_defaults now understands --defaults-group-suffix
Remove usage of my_tempnam() (not safe function)
if( -> if ( and while( to while (

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

into mysql.com:/space/my/mysql-5.0

into  krsna.patg.net:/home/patg/mysql-5.0

  Added a test case for bug #11745.
sql_select.cc:
  Fixed bug # 11745.
  Added support of where clause for queries with FROM DUAL.
sql_yacc.yy:
  Fixed bug # 11745.
  Added optional where clause for queries with FROM DUAL.

WHERE statement"

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

  Fixed bug #11885.
sql_select.cc:
  Fixed bug #11885.
  Predicates of the forms 'a IN (v)' 'a NOT IN (v)' now
  is replaced by 'a=v' and 'a<>v' at the parsing stage.
sql_yacc.yy:
  Fixed bug #11885.
  Predicates of the forms 'a IN (v)' 'a NOT IN (v)' now 
  is replaced by 'a=v' and 'a<>v' at the parsing stage.

  Fixed bug #11853.
  Corrected the code of the range optimization for
  NOT IN and NOT BETWEEN.
range.test, range.result:
  Fixed bug #11853.

into  mysql.com:/media/sda1/mysql/mysql-5.0-merge

"Negative integer keys incorrectly substituted for 0 during range analysis."

The problem is that the range optimizer incorrectly replaces any negative
constant with '0' for all types except BIGINT because the method save_in_field()
casts negative integers to non-negative. This causes incorrect query
results where (0 = any_negative_number).

The problem caused by this bug is fixed by the patch for BUG#11185.
That patch constitutes an optimization due to which the problem code is
never called with negative constants. This patch adds a test so we are sure
that the problem does not reappear.