Merge jcole@work.mysql.com:/home/bk/mysql

/bin/rm -f config.cache mysql-*.tar.gz

aclocal; autoheader; aclocal; automake; autoconf

CC=ccc CFLAGS="-fast -O3 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -mcpu=ev6 -Wa,-mev6" CXXLDFLAGS='/usr/lib/compaq/libots-2.2.7/libots.so /usr/lib/compaq/cpml-5.0.0/libcpml_ev6.a' ./configure --prefix=/usr/local/mysql --disable-shared --with-extra-charsets=complex

CC=ccc CFLAGS="-fast -O3 -fomit-frame-pointer" CXX=gcc CXXFLAGS="-O6 -fomit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -mcpu=ev6 -Wa,-mev6" CXXLDFLAGS='/usr/lib/compaq/libots-2.2.7/libots.so /usr/lib/compaq/cpml-5.0.0/libcpml_ev6.a' ./configure --prefix=/usr/local/mysql --disable-shared --with-extra-charsets=complex --enable-thread-safe-client

make

if [ $? = 0 ]

then

Mail by sasha, should be rewritten as a HOWTO sometimes

-----------

I have set up a repository with BitKeeper on work. There are still some things

about it that I would like to learn, but I have gotten far enough with it to

replace CVS functionality were are currently using, so let's just go ahead and

get started on it. Please follow the instructions below (make sure to save the

message for future reference):

a) http://www.bitmover.com/download

        user: beta

        password: get bitkeeper

  get the version appropriate for your platform - download it to a temp

directory, chmod +x  and then run it. You will have to tell it which directory

to install, for consistency, let's use /usr/local/bin

b) we will take advantage of bk capablity of working with master/slave

repositories. The master will be on work.mysql.com, the slaves will be our

individual machines. The master repository has already been set up on work, so

you will need just to set up a slave repository on your machine:

  mkdir bk

  cd bk

  bk clone yourusername@work:/home/bk/mysql mysql

  cd mysql

  bk -r edit

Now you have the entire source tree in the current directory. Let's compile it:

 BUILD/compile-pentium-debug

After you edit a file, you need to check it in using bk citool or bk ci

filename. Note that ci is different than commit - you ci a file, but you commit

a change set. This is a very nice concept - instead of thinking of each

individual file as CVS does, bk groups the changes you are making and allows you

to document what you actually did between the commits as a whole, rather than

just commenting on every file. When you commit, bk will ask you to comment on

the change set.

Commit is done just to your local repository. To make your changes global, you

will need to run bk push. Be careful with that - it is a good idea to run bk

push -l -n first too see what you are just about to push to the master

repository.

When somebody does a push, you will be getting a email ( I will set this up to

day). You will then need to execute bk pull to update your sources. If there are

any conflicts, bk will force you to resolve them by asking you questions on what

to do with each conflict.

To learn more about bk, use bk helptool - I will be doing this a lot in the next

couple of days :-) If you find bugs or have questions/feature

suggestions/comments for developers, feel free to e-mail dev@bitmover.com .

Their developers, and especially the president of the company Larry McCoy really

like MySQL and are very anxious to help us. Make sure it is obvious that you

work for MySQL, of course. And, of course, do not bug them with little things

that you can figure out on your own or with my help - they were nice to offer us

support, but we should not abuse it.

If you are working on 3.23 MySQL source, please make sure to convert to bk ASAP

before you do any further developement - otherwise, things will get

exponentially worse as the code mass increases. I will work on mysql-4.0 next

and try to set it up so that when we update 3.23 source tree, the update makes

it to mysql-4.0.

  and then we read the rows in the sorted order into a row buffer

  (record_buffer) .

@node Coding guidelines

@chapter Coding guidelines

- We are using bitkeeper (www.bitkeeper.com) for source management.

- You should use the MySQL 3.23 or MySQL 4.0 source for all developments.

- If you have any questions about the MySQL source, you can post these

  to developers@mysql.com and we will answer them.

  Note that we will shortly change the name of this list to

  internals@mysql.com, to more accurately reflect what should be

  posted to this list.

- Try to write code in a lot of black boxes that can be reused or at

  least have a clean interface

- Reuse code;  There is already in MySQL a lot of algorithms for list handling,

  queues, dynamic and hashed arrays, sorting...) that can be reused.

- Try to always write optimized code, so that you don't have to

  go back and rewrite it a couple of months later.  It's better to

  spend 3 times as much time designing and writing and optimal function than

  having to do it all over again later on.

- Avoid CPU wasteful code, even where it does not matter, so that

  you will not develop sloppy coding habits.

- If you can write it in fewer lines, do it (as long as the code will not

  be slower or much harder to read)

- do not check the same pointer for NULL more than once.

- Use long function and variable names in English;  This makes your

  code easier to read.

- Think assembly - make it easier for the compiler to optimize your code.

- Comment your code when you do something that someone else may think

  is 'not trivial'.

- Use the my_ functions like my_read/my_write/my_malloc() that you can

  find in the mysys library instead of the direct system calls;  This

  will make your code easier to debug and more portable.

- use libstring functions instead of standard libc string functions

  whenever possible

- Avoid using alloc (its REAL slow);  For memory allocations that only

  needs to live for the lifetime of one thread, on should use

  sql_alloc() instead.

- Before doing big design decision, please first post a summary of

  what you want to do, why you want to do it and how you plan to do

  it.  This way we can easily provide you with feedback and also

  easily discuss is throughly if some other developer thinks there is better

  way to do the same thing!

- Use my_var as opposed to myVar or MyVar ( _ rather than dancing SHIFT

  to spearate words in identifiers)

- class names start with a capital 

- structure types are typedefed to all caps identifier

- #defines are capitalized

- matching { are in the same column

 - functions return 0 on success , non-zero on error, so you can do

  if(a() || b() || c()) { error("something went wrong");}

- goto is ok if not abused

- avoid default variable initalizations, use LINT_INIT() if the

  compiler complains after making sure that there is really no way

  the variable can be used uninitialized

- Do not instantiate a class if you do not have to

- Use pointers rather than array indexing when operating on strings

@node Index

@unnumbered Index

			@bench_dirs@ support-files

# Relink after clean

CLEANFILES =		linked_client_sources linked_server_sources

CLEANFILES =		linked_client_sources linked_server_sources linked_libmysql_sources linked_libmysql_r_sources

# This is just so that the linking is done early.

config.h:	linked_client_sources linked_server_sources

linked_libmysql_sources:

	cd libmysql; $(MAKE) link_sources

	echo timestamp > linked_libmysql_sources

linked_libmysql_r_sources: linked_libmysql_sources

	cd libmysql_r; $(MAKE) link_sources

	echo timestamp > linked_libmysql_r_sources

#avoid recursive make calls in sql directory

linked_server_sources: