into  debian.(none):/M51/push-5.1

into  debian.(none):/M51/push-5.1

into  debian.(none):/M51/bug16635-5.1

into  debian.(none):/M50/bug16635-5.0

to 150 or 107 characters for those messages which are generated
by the embedded server during release builds.

This fixes bug#16635:
   Error messages wrong: absolute path names, "%s" format code

See the bug report or the changelog for "sql/share/english/errmsg.txt"
for instructions how to do that with other languages, 
even at the customer site, and for the restrictions to keep.

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

  Post-merge fix.

  Post-merge fix.

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

for enabling threads.  However, duplicate AC_PROG_* macros in the
innobase plug.in file were resetting $CC and causing link errors.

As AC_PROG_* macros are already used in the main configure.in file
there should be no need for them to be duplicated here too.

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime

into  bodhi.(none):/opt/local/work/mysql-5.0-runtime

When the SQL_BIG_RESULT flag is specified SELECT should store items from the
select list in the filesort data and use them when sending to a client.
The get_addon_fields function is responsible for creating necessary structures
for that. But this function was allowed to do so only for SELECT and
INSERT .. SELECT queries. This makes the SQL_BIG_RESULT useless for
the CREATE .. SELECT queries.

Now the get_addon_fields allows storing select list items in the filesort
data for the CREATE .. SELECT queries.

Changed the default location of the log output to LOG_FILE,
for backward compatibility with MySQL 5.0

  Put back old code to check stack direction at configure time

into  magare.gmz:/home/kgeorge/mysql/autopush/B29644-5.0-opt

into  olga.mysql.com:/home/igor/mysql-5.0-opt

  Limit the fix for bug 28591 to InnoDB only

If a primary key is defined over column c of enum type then 
the EXPLAIN command for a look-up query of the form
  SELECT * FROM t WHERE c=0
said that the query was with an impossible where condition though the
query correctly returned non-empty result set when the table indeed 
contained rows with error empty strings for column c. 

This kind of misbehavior was due to a bug in the function 
Field_enum::store(longlong,bool) that erroneously returned 1 if
the the value to be stored was equal to 0. 
Note that the method 
Field_enum::store(const char *from,uint length,CHARSET_INFO *cs)
correctly returned 0 if a value of the error empty string 
was stored. 

into  magare.gmz:/home/kgeorge/mysql/autopush/B28951-5.0-opt

into  mysql.com:/home/hf/work/29494/my41-29494

into  mysql.com:/home/hf/work/29494/my50-29494

into  mysql.com:/home/hf/work/29494/my51-29494

into  mysql.com:/home/hf/work/29494/my51-29494

into  mysql.com:/home/hf/work/29494/my50-29494

into  olga.mysql.com:/home/igor/mysql-5.0-opt

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

  Additional test case fix for bug #29338.

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29911

into  gleb.loc:/home/uchum/work/bk/5.1-opt

into  gleb.loc:/home/uchum/work/bk/5.0-opt

into  olga.mysql.com:/home/igor/dev-opt/mysql-5.0-opt-bug29911

into  bodhi.(none):/opt/local/work/mysql-5.1-runtime