Main problem: mysql 5.1 cannot read binlogs from 4.1.
Subproblem 1: There is a mistake in sql_ex_info::init. The read_str()
function updates its first argument to point to the next character to
read. However, it is applied only to a copy of the buffer pointer, so the
real buffer pointer is not updated.
Fix 1: do not take a copy of the buffer pointer. The copy was needed
because sql_ex_info::init does not use the const attribute on some of its
arguments. So we add the const attribute, too.
Subproblem 2: The first BINLOG statement is asserted to be a
FORMAT_DESCRIPTION_LOG_EVENT, but 4.1 binlogs begin with START_EVENT_V3.
Fix 2: allow START_EVENT_V3 too.

into  mail.hezx.com:/media/sda3/work/mysql/bkwork/bug#32205/5.1

into  mail.hezx.com:/media/sda3/work/mysql/bkwork/versional/merge-51

into  riska.(none):/home/sven/bk/b27779-old_row_events/5.1-new-rpl

into  mail.hezx.com:/media/sda3/work/mysql/bkwork/versional/merge-51

into  mail.hezx.com:/media/sda3/work/mysql/bkwork/versional/merge-51

Mask binlog positions, error, warning and other information that are not significant for the test

Problem: Replication fails when master is mysql-5.1-wl2325-5.0-drop6 and
slave is mysql-5.1-new-rpl. The reason is that, in
mysql-5.1-wl2325-5.0-drop6, the event type id's were different than in
mysql-5.1-new-rpl.
Fix (in mysql-5.1-new-rpl):
 (1) detect that the server that generated the events uses the old
format, by checking the server version of the format_description_log_event
This patch recognizes mysql-5.1-wl2325-5.0-drop6p13-alpha,
mysql-5.1-wl2325-5.0-drop6, mysql-5.1-wl2325-5.0, mysql-5.1-wl2325-no-dd.
 (2) if the generating server is old, map old event types to new event
types using a permutation array.

I've also added a test case which reads binlogs for four different
versions.

into  riska.(none):/home/sven/bk/b26395-autocommit-xa/5.1-new-rpl

into  mail.hezx.com:/media/sda3/work/mysql/bkwork/bug#28908/5.1

into  riska.(none):/home/sven/bk/b26395-autocommit-xa/5.1-new-rpl
Should really not be merged, will undo later

Now, every transaction (including autocommit transactions) start with
a BEGIN and end with a COMMIT/ROLLBACK in the binlog.
Added a test case, and updated lots of test case result files.

into  mail.hezx.com:/media/sda3/work/mysql/bkwork/bug#28908/5.0

into  capulet.kindahl.net:/home/mats/devel/fix-mysql-5.0-rpl

When set the server-id dynamically, the server_id member of current thread is not updated.

Update the server_id member of current thread after updated the global variable value.

into  riska.(none):/home/sven/bkroot/5.1-new-rpl

Complementary patch since LOAD DATA INFILE was not covered in
the previous patch.

This patch adds a check so that the slave skip counter is not
decreased to zero if seeing a BEGIN_LOAD_QUERY_EVENT,
APPEND_BLOCK_EVENT, or CREATE_FILE_EVENT since these cannot
end a group. The group is terminated by an EXECUTE_LOAD_QUERY_
EVENT or DELETE_FILE_EVENT.

into  dl145h.mysql.com:/data0/mkindahl/mysql-5.1-rpl

into  dl145h.mysql.com:/data0/mkindahl/mysql-5.1-rpl

into  hezx.(none):/media/sda3/work/mysql/bkwork/bug#32205/mysql-5.1-new-rpl

fine

The reason of this bug is that when mysqlbinlog dumps a query, the query is written to
output with a delimeter appended right after it, if the query string ends with a '--'
comment, then the delimeter would be considered as part of the comment, if there are any
statements after this query, then it will cause a syntax error.

Start a newline before appending delimiter after a query string

The reason of this bug is that when mysqlbinlog dumps a query, the query is written to
output with a delimeter appended right after it, if the query string ends with a '--'
comment, then the delimeter would be considered as part of the comment, if there are any
statements after this query, then it will cause a syntax error.

Start a newline before appending delimiter after a query string

into  riska.(none):/home/sven/bk/b32407-5.1-new-rpl-mysqlbinlog_base64