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

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

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

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

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

into  trift2.:/MySQL/M51/mysql-5.1

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

READ_ONLY token was accidentally placed into wrong place
('ident' rule). The proper place is in the 'keyword_sp' rule.

The manual should be re-generated after this patch, because
the manual depends on the 'keyword_sp' rule.

into  buzz.(none):/home/davi/mysql-5.1-runtime

must match the order which they were declared in the class definition. 

Rename client_last_error to last_error and client_last_errno to last_errno
to not break connectors which use the internal net structure for error handling.

The problem is that passing anything other than a integer to a limit
clause in a prepared statement would fail. This limitation was introduced
to avoid replication problems (e.g: replicating the statement with a
string argument would cause a parse failure in the slave).

The solution is to convert arguments to the limit clause to a integer
value and use this converted value when persisting the query to the log.

sporadically.

(show_check.test fails sporadically).

Fix test case for Bug#12183 to make it stable.

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

to reach the desired value.

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-build

Disable the test case.

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

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

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

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt

into  quad.:/mnt/raid/alik/MySQL/devel/5.1-rt-merged

into  quad.:/mnt/raid/alik/MySQL/devel/5.0-rt-merged

into  mysql.com:/Users/davi/mysql/mysql-5.1-runtime

Bug#34678 @@debug variable's incremental mode

The problem is that the per-thread debugging settings stack wasn't
being deallocated before the thread termination, leaking the stack
memory. The chosen solution is to push a new state if the current
is set to the initial settings and pop it (free) once the thread
finishes.