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

  Rearrange out of order options in option struct.

into  snake-hub.snake.net:/src/extern/MySQL/bk/mysql-5.0

  Fix out of order entries in option struct.

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

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

Add new parameter to do_eval so that only unescaped variables in input string is expanded and rest of string is left untouched.

into  mysql.com:/usr_rh9/home/elkin.rh9/MySQL/FIXES/5.0-bug17265

To quote Timour review lines:

The actual cause of the bug is that sql_base.cc:setup_wild()
sets "select_lex->with_wild = 0" (in the end of the function) once
it expands all wild-cards, and wild-card expansion is done during
the prepare phase. During this phase we replace all "*" with the
corresponding items, which for views happen to be references to
references. When we do execute, select_lex->with_wild = 0, and
all "*" are already replaced by the corresponding items, which
in the case of views need to be dereferenced first.

Fixed by refining the assert. Regression test for the bug is rpl_row_view01,
as was reported.

The problem was that error flag was not reset.

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

into  mysql.com:/opt/local/work/mysql-5.0-runtime

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

When a too long field is used for a key, only a prefix part of the field is 
used. Length is reduced to the max key length allowed for storage. But if the
field have a multibyte charset it is possible to break multibyte char
sequence. This leads to the failed assertion in the innodb code and 
server crash when a record is inserted.

The make_prepare_table() now aligns truncated key length to the boundary of
multibyte char.

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

into  mysql.com:/home/cps/mysql/devel/im/5.0-im-fix-race

duration of the whole 'flush instances'. As a consequence,
it was possible to query instance map, while it is in the
inconsistent state. The patch was reworked after review.

Bug#14857 Reading dump files with single statement stored routines fails.Bug #14857  	Reading dump files with single statement stored routines fails.
 - Add tests, fixed by patch for 16878

into  mysql.com:/home/cps/mysql/devel/im/5.0-im-add-error-message

connections correctly".
Recommit with the max timeout value in sync with the comment.

 - Add comments with embeded veriosn info around the parts of the view syntax that are only supported by a certain version of MySQL Server

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

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

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

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

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

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

into mysql.com:/home/hf/work/mysql-5.0.w2645

into  mysql.com:/usr/local/mysql/mysql-5.0

fails with --vardir option.

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

Fix for BUG#13897 "failure to do SET SQL_MODE=N where N is a number > 31" (the original bug's title isn't the simplest
symptom). sys_var::check_set() was wrong. mysqlbinlog makes use of such SET SQL_MODE=N
(where N is interpreted like if SQL_MODE was a field of type SET), so
this bug affected recovery from binlogs if the server was running with certain SQL_MODE values,
for example the default values on Windows (STRICT_TRANS_TABLES); to work around this bug people
had to edit mysqlbinlog's output.

if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch. 
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.