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

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

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

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

into  sanja.is.com.ua:/home/bell/mysql/bk/work-qc-4.1

- fixed test

into mysql.com:/space/my/mysql-4.1

   to assign a potential existing mysql user to the correct user group (BUG#12823) 

 - added a usermod call to assign a potential existing mysql user to the
   correct user group (BUG#12823)
 - Save the perror binary built during Max build so it supports the NDB
   error codes (BUG#13740)
 - added a separate macro "mysqld_group" to be able to define the
   user group of the mysql user seperately, if desired.

into deer.(none):/home/hf/work/mysql-4.1.clean

into  mysql.com:/home/my/mysql-4.0

- No need to check *ref when ref is checked (Simple optimization fix)

into  ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-4.1-tmp

into moonbone.local:/work/13535-bug-4.1-mysql

into mysql.com:/Users/kent/mysql/bk/mysql-4.1

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

into  mysql.com:/usr/home/ram/work/mysql-4.1

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

into  mysql.com:/home/jimw/my/mysql-4.1-clean

into  mysql.com:/home/jimw/my/mysql-4.1-clean

  Bug #7672 after merge fix

into  mysql.com:/home/jimw/my/mysql-4.1-clean

into  mysql.com:/home/jimw/my/mysql-4.1-clean

To force a restart at the end of test, the option file must be non-empty, it's not enough if it exists and is empty.

into  mysql.com:/home/jimw/my/mysql-4.1-clean

into  mysql.com:/home/jimw/my/mysql-4.1-clean

into  mysql.com:/home/jimw/my/mysql-4.1-clean

into moonbone.local:/work/13535-bug-4.1-mysql

  1. it's wrong to use memcpy() for overlapped areas;
  2. we use it only once.
During merge to 4.1 will remove a memcpy_overlap() call 
from strings/ctype-tis620.c as well in order to fix 
bug #10836: ctype_tis620 test failure with ICC-compiled binaries on IA64.

in short we now record whenever the slave I/O thread ignores a master's event because of its server id,
and use this info in the slave SQL thread to advance Exec_master_log_pos. Because if we
do not, this variable stays at the position of the last executed event, i.e. the last *non-ignored*
executed one, which may not be the last of the master's binlog (and so the slave *looks* behind
the master though it's data-wise it's not).