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

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

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

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

if item_func->argument_count()==0

into  magare.gmz:/home/kgeorge/mysql/work/merge-5.1-opt

  Updated test case for bug #29294.

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

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

  Test case update for bug #29294.

  Windows compilation error fix.

The `SELECT 'r' INTO OUTFILE ... FIELDS ENCLOSED BY 'r' ' statement
encoded the 'r' string to a 4 byte string of value x'725c7272'
(sequence of 4 characters: r\rr).
The LOAD DATA statement decoded this string to a 1 byte string of
value x'0d' (ASCII Carriage Return character) instead of the original
'r' character.
The same error also happened with the FIELDS ENCLOSED BY clause
followed by special characters: 'n', 't', 'r', 'b', '0', 'Z' and 'N'.

NOTE 1: This is a result of the undocumented feature: the LOAD DATA INFILE
recognises 2-byte input sequences like \n, \t, \r and \Z in addition
to documented 2-byte sequences: \0 and \N. This feature should be
documented (here backspace character is a default ESCAPED BY character,
in the real-life example it may be any ESCAPED BY character).

NOTE 2, changed behaviour:
Now the `SELECT INTO OUTFILE' statement with the `FIELDS ENCLOSED BY'
clause followed by one of: 'n', 't', 'r', 'b', '0', 'Z' or 'N' characters
encodes this special character itself by doubling it ('r' --> 'rr'),
not by prepending it with an escape character.

into  whalegate.ndb.mysql.com:/home/tomas/mysql-5.1-new-rpl

into  mysql.com:/home/bar/mysql-work/mysql-5.1-new-rpl

into  mysql.com:/home/bar/mysql-work/mysql-5.0.b27345

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

asserts debug binary

We can't reliably check if the binary log is opened without 
acquiring its mutex. 
Fixed by removing this check.

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

into  perch.ndb.mysql.com:/home/jonas/src/51-telco-gca

  Not very clever fix for DIH incorrect REDO handling
  - Dont report GCP_SAVE_CONF until first LCP has been complete during NR

into  dator6.(none):/home/mikael/mysql_clones/bug18198

into  mysql.com:/nfsdisk1/lars/bk/mysql-5.1-new-rpl

into  mysql.com:/nfsdisk1/lars/bk/mysql-5.0-rpl

into  mysql.com:/nfsdisk1/lars/bk/mysql-5.1-new-rpl

into  mysql.com:/nfsdisk1/lars/bk/mysql-5.0-rpl

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

into  perch.ndb.mysql.com:/home/jonas/src/51-telco-gca

  In TC init node status for already started nodes during node restart
  (not present in 5.1)

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-5.1-merge

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge

into  mysql.com:/nfsdisk1/lars/MERGE/mysql-4.1-merge

This bug may manifest itself not only with the queries for which
the index-merge access method is chosen. It also may display
itself for queries with DISTINCT.

The bug was in how the Unique::get method used the merge_buffers
function. To compare elements in the the queue employed by
merge_buffers() it must use the buffpek_compare function rather
than the function for binary comparison. 

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

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