comments are fixed as was suggested in reviews.

bugs/wls in cset's comments. The targetted BUG's or WL's identifier must be specified
the first in the comments. The referred bugs wls can be typed in same as the targeted
clickable format.
If the the target of the fix is a WL and there are some references to bugs
then the first found reference is regarded as "co-target" so that the bug's identifier
comes up on the subject line along with the WL's and commit mail will update
the bug page. The latter feature can be disarmed (if there is no need to update
the referred bug's page) with typing the first a pseudo-bug pattern (bug#0).

This paticular cset will generate subject line containing bug#0 (as it was the first
referred) whereas the old version would put in the subject line the last referred
pattern (e.g bug#2147483648).

into  mysql.com:/usr/home/bar/mysql-4.1.b23451v2

fixing a flow of the test

into  dsl-hkibras-fe30f900-107.dhcp.inet.fi:/home/elkin/MySQL/TEAM/BARE/mysql-4.1-rpl

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

  
  Problem: GROUP_CONCAT on a multi-byte column can truncate
  in the middle of a multibyte character when applying
  group_concat_max_len limit. It produces an invalid
  multi-byte character in the result string.
  
The second, easier version - reusing old "warning_for_row" flag,
instead of introducing of "result_is_full" - which was
added in the previous commit.

into  zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-4.1-maint

into  shellback.(none):/home/msvensson/mysql/mysql-4.1-maint

  Raise version number to 4.1.23

into  kpdesk.mysql.com:/home/thek/dev/mysql-4.1-maint

- 'false' not defined in C, use FALSE instead.

into  mysql.com:/usr/home/ram/work/bug22913/my41-bug22913

We don't check for errors that may occur during data printing.

into  bodhi.local:/opt/local/work/mysql-4.1-runtime

into  shellback.(none):/home/msvensson/mysql/mysql-4.1-maint

into  shellback.(none):/home/msvensson/mysql/mysql-4.1-maint

into  kpdesk.mysql.com:/home/thek/dev/mysql-4.1-maint

 - Only read *.pid
 - Only allow it to contain a number 

- Because my_seek actually is capable of returning an error code we should
  exploit that in the best possible way.
- There might be kernel errors or other errors we can't predict and capturing
  the return value of all system calls gives us better understanding of
  possible errors.

into  mysql.com:/usr/home/ram/work/bug23412/my41-bug23412

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug21915

If the user has specified --max-connections=N or --table-open-cache=M
options to the server, a warning could be given that some values were
recalculated, and table-open-cache could be assigned greater value.

Note that both warning and increase of table-open-cache were totally
harmless.

This patch fixes recalculation code to ensure that table-open-cache will
be never increased automatically and that a warning will be given only if
some values had to be decreased due to operating system limits.

No test case is provided because we neither can't predict nor control
operating system limits for maximal number of open files.

into  shellback.(none):/home/msvensson/mysql/mysql-4.1-maint

 - Wait in loop with small sleep until tables has been renamed

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

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

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

  Still leakage, make sure all unlinked operations are put back so they will be release
  (on failing blob operations, when AO_IgnoreError)

Backport of the fix for bug #8143: A date with value 0 is treated as a NULL value

into  moonlight.intranet:/home/tomash/src/mysql_ab/mysql-4.1-bug18819

If the error happens during DELETE IGNORE, nothing could be send to the
client, thus leaving it frozen expecting the reply.

The problem was that if some error occurred, it wouldn't be reported to
the client because of IGNORE, but neither success would be reported.

MySQL 4.1 would not freeze the client, but will report

  ERROR 1105 (HY000): Unknown error

instead, which is also a bug.

The solution is to report success if we are in DELETE IGNORE and some
non-fatal error has happened.

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

into  mysql.com:/windows/Linux_space/MySQL/mysql-4.1-ndb