mysql-test/t/bdb-crash.test:
  added newline
sql/ha_berkeley.cc:
  added a commet

into eagle.mysql.r18.ru:/home/vva/work/BUG_2342/mysql-4.0

"Running ANALYZE TABLE on bdb table inside a transaction hangs server thread"

1. added new status HA_ADMIN_REJECT and processing of it in mysql_admin_table
2. got ha_berkley::analyze to return HA_ADMIN_REJECT if there are any 
 transactions with the table.. 


mysql-test/r/bdb-crash.result:
  added test for bug #2342 
  "Running ANALYZE TABLE on bdb table inside a transaction hangs server thread"
mysql-test/t/bdb-crash.test:
  added test for bug #2342 
  "Running ANALYZE TABLE on bdb table inside a transaction hangs server thread"
sql/ha_berkeley.cc:
  fixed bug #2342 
  "Running ANALYZE TABLE on bdb table inside a transaction hangs server thread"
  
  we have to return new status "HA_ADMIN_REJECT" for ha_berkley::analyze 
  if there are any transaction for this table 
  so as bdb documentation says:
  "The DB->stat method cannot be transaction protected"
sql/handler.h:
  added new status of table info "HA_ADMIN_REJECT"
  
  We have to return this status for bdb tables which 
  have any active transactions so as bdb-documentation says:
  "The DB->stat method cannot be transaction-protected"
sql/sql_table.cc:
  added processing of the new status HA_ADMIN_REJECT in mysql_admin_table
  (reason to add this status is explained in comment 
  for commit on sql/handler.h)

into sinisa.nasamreza.org:/mnt/work/mysql-4.0

into hundin.mysql.fi:/home/heikki/mysql-4.0

  Backport from 4.1: make mem_current_allocated_memory global variable


innobase/mem/mem0dbg.c:
  Backport from 4.1: make mem_current_allocated_memory global variable

into sinisa.nasamreza.org:/mnt/work/mysql-4.0

  result of the test case for FORCE INDEX on ORDER BY
order_by.test:
  test case for FORCE INDEX on ORDER BY
sql_select.cc:
  Changing behaviour that MySQL server takes FORCE INDEX clause into account when optimising ORDER BY clause


sql/sql_select.cc:
  Changing behaviour that MySQL server takes FORCE INDEX clause into account when optimising ORDER BY clause
mysql-test/t/order_by.test:
  test case for FORCE INDEX on ORDER BY
mysql-test/r/order_by.result:
  result of the test case for FORCE INDEX on ORDER BY

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

mysql-test/r/alter_table.result:
  Updated tests
mysql-test/t/alter_table.test:
  Updated tests

BitKeeper/etc/logging_ok:
  auto-union
scripts/mysqlbug.sh:
  Auto merged
sql/sql_parse.cc:
  Auto merged
mysql-test/t/alter_table.test:
  Merge code with 3.23
sql/nt_servc.cc:
  use original code

service backport from 4.0


mysql-test/t/alter_table.test:
  Improved test case
sql/nt_servc.cc:
  service backport from 4.0
BitKeeper/etc/logging_ok:
  Logging to logging@openlogging.org accepted

into sanja.is.com.ua:/home/bell/mysql/bk/work-alter-3.23

cleanup (VERSION variable)

into serg.mylan:/usr/home/serg/Abk/mysql-4.0

bug#3134


BitKeeper/deleted/.del-post-incoming~9f2168f531f09f3b:
  Delete: BitKeeper/triggers/post-incoming
BitKeeper/deleted/.del-post-outgoing~1dd3d8f0f6e8f3cd:
  Delete: BitKeeper/triggers/post-outgoing

into sinisa.nasamreza.org:/mnt/work/mysql-4.0

Shouldn't be moved to 4.1


myisam/mi_check.c:
  only set key_map if necessary

into sanja.is.com.ua:/home/bell/mysql/bk/work-conf-4.0


mysys/default.c:
  Auto merged

into serg.mylan:/usr/home/serg/Abk/mysql-4.0

mysql-test/t/alter_table.test:
  test for BUG#3270 added

into sinisa.nasamreza.org:/mnt/work/mysql-4.0

BitKeeper/deleted/.del-libmysql.def~f5dffcb3ed925d28:
  Delete: VC++Files/libmysql/libmysql.def
VC++Files/innobase/innobase.dsp:
  'com' module no longer exists.
VC++Files/strings/MASM6x/strings.dsp:
  Add strnlen
VC++Files/strings/strings.dsp:
  Add strnlen

  Actually, assembler is used onnly on 32-bit x86 Win, and no need to exclude Netware specifically


innobase/sync/sync0sync.c:
  Actually, assembler is used onnly on 32-bit x86 Win, and no need to exclude Netware specifically

into hundin.mysql.fi:/home/heikki/mysql-4.0

  Fix typo __NETWARE --> __NETWARE__ in mutex creation


innobase/sync/sync0sync.c:
  Fix typo __NETWARE --> __NETWARE__ in mutex creation

into sinisa.nasamreza.org:/mnt/work/mysql-4.0

   A test case for the bug  that allowed table names to be used in ORDER BY columns (But #3064)
union.test:
  A test case for the bug  that allowed table names to be used in ORDER BY columns (But #3064)
sql_union.cc:
  A fix for a bug that allowed table names to be used in ORDER BY columns (But #3064)


sql/sql_union.cc:
  A fix for a bug that allowed table names to be used in ORDER BY columns (But #3064)
mysql-test/t/union.test:
  A test case for the bug  that allowed table names to be used in ORDER BY columns (But #3064)
mysql-test/r/union.result:
   A test case for the bug  that allowed table names to be used in ORDER BY columns (But #3064)

mysql-test/r/grant_cache.result:
  right results in query cache
mysql-test/t/grant_cache.test:
  proving new results
sql/sql_cache.cc:
  fixed statistic calculating in query cahe

test="\"#no comment here"#real comment

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

this is better in this case:
- imagine user1 has created a temp table
- imagine user2 does FLUSH TABLES WITH READ LOCK, then takes a backup,
then RESET MASTER then UNLOCK TABLES, like mysqldump --first-slave
- then in the binlog you will finally have the DROP TEMPORARY TABLE,
but not the CREATE TEMPORARY TABLE, so when you later restore with
mysqlbinlog|mysql, mysql will complain that table does not exist.
Replication was already protected of this (it processes DROP TEMPORARY
TABLE as if there was a IF EXISTS), now I add it directly to the query
for mysqlbinlog|mysql to work.


mysql-test/r/drop_temp_table.result:
  result update (query changed)

  Correct previous bk commit comment about page splits: actually, in versions < 4.0.19 space utilization is very poor if 1500 - 8000 byte rows are inserted in the order of the primary key


innobase/btr/btr0btr.c:
  Correct previous bk commit comment about page splits: actually, in versions < 4.0.19 space utilization is very poor if 1500 - 8000 byte rows are inserted in the order of the primary key

  Improve space utilization if we have 3 kB - 8 kB rows to insert in the order of the primary key
btr0cur.c:
  Fix bug: The row count and key cardinality estimate was grossly too small if each clustered index page only contained one record


innobase/btr/btr0cur.c:
  Fix bug: The row count and key cardinality estimate was grossly too small if each clustered index page only contained one record
innobase/btr/btr0btr.c:
  Improve space utilization if we have 3 kB - 8 kB rows to insert in the order of the primary key

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

into mysql.com:/space/my/mysql-4.0-build