This article is obsolete. We don't use bzr anymore. This howto needs to be rewritten to explain how to create a merge tree in git.

Merge tree in the context of this HOWTO is a tree created specifically to simplify merges of third-party packages into MariaDB. WIth a merge tree there's a clear separation between upstream changes and our changes and in most cases bzr can do the merges automatically.

Here's how I created a merge tree for pcre:

• prerequisites: we already have pcre in the MariaDB tree, together with our changes (otherwise one can trivially create a bzr repository out of source pcre tarball).

• create an empty repository:

mkdir pcre
cd pcre
bzr init

• download pcre source tarball of the same version that we have in the tree — pcre-8.34.tar.bz2

• unpack it in the same place where the files are in the source tree:

• Add files to the repository with the same file-ids as in the MariaDB tree!

• All done. Commit and push

• Now null-merge that into your MariaDB tree. Note, that for the initial merge you need to specify the revision range 0..1

• Remove pcre files that shouldn't be in MariaDB tree, revert all changes that came from pcre (remember — it's a null-merge, pcre-8.34 is already in MariaDB tree), rename files in place as needed, resolve conflicts:

• Verify that the tree is unchanged and commit:

• Congratulations, your new merge tree is ready!

Now see .

_{This page is licensed: CC BY-SA / Gnu FDL}

Note: This page is obsolete. The information is old, outdated, or otherwise currently incorrect. We are keeping the page for historical reasons only. Do not rely on the information in this article.

Merging from MySQL into MariaDB

Merging code changes from MySQL bzr repository

We generally merge only released versions of MySQL into MariaDB trunk. This is to be able to release a well-working release of MariaDB at any time, without having to worry about including half-finished changes from MySQL. Merges of MySQL revisions in-between MySQL releases can still be done (eg. to reduce the merge task to smaller pieces), but should then be pushed to the maria-5.1-merge branch, not to the main lp:maria branch.

The merge command should thus generally be of this form:

As a general rule, when the MySQL and MariaDB side has changes with the same meaning but differing text, pick the MySQL variant when resolving this conflict. This will help reduce the number of conflicts in subsequent merges.

Buildbot testing

To assist in understanding test failures that arise during the merge, we pull the same revision to be merged into the lp:maria-captains/maria/mysql-5.1-testing tree for buildbot test. This allows to check easily if any failures introduced are also present in the vanilla MySQL tree being merged.

Helpful tags and diffs

To help keep track of merges, we tag the result of a merge:

For example, when merging MySQL 5.1.39, the commit of the merge would be tagged like this:

The right-hand parent of tag:mariadb-merge-mysql-5.1.39 will be the revision tag:mysql-5.1.39. The left-hand parent will be a revision on the MariaDB trunk.

When merging, these tags and associated revisions can be used to generate some diffs, which are useful when resolving conflicts. Here is a diagram of the history in a merge:

Here,

• 'B' is the base revision when MariaDB was originally branched from MySQL.

• 'A0' is the result of the last MySQL merge, eg.tag:mariadb-merge-mysql-5.1.38.

• 'Y0' is the MySQL revision that was last merged, eg.tag:mysql-5.1.38.

Then, these diffs can be useful:

• 'bzr diff -rY0..before:A1' - this is the MariaDB side of changes to be merged.

• 'bzr diff -rY0..Y1' - this is the MySQL side of changes to be merged.

• 'bzr diff -rA0..before:A1' - these are the new changes on the MariaDB side to be merged; this can be useful do separate them from other MariaDB-specific changes that have already been resolved against conflicting MySQL changes.

Merging documentation from MySQL source tarballs

The documentation for MySQL is not maintained in the MySQL source bzr repository. Therefore changes to MySQL documentation needs to be merged separately.

Only some of the MySQL documentation is available under the GPL (man pages, help tables, installation instructions). Notably the MySQL manual is not available under the GPL, and so is not included in MariaDB in any form.

The man pages, help tables, and installation instruction READMEs are obtained from MySQL source tarballs and manually merged into the MariaDB source trees. The procedure for this is as follows:

There is a tree on Launchpad used for tracking merges:

(At the time of writing, this procedure only exists for the 5.1 series of MySQL and MariaDB. Additional merge base trees will be needed for other release series.)

This tree must only be used to import new documentation files from new MySQL upstream source tarballs. The procedure to import a new set of files when a new MySQL release happens is as follows:

• Download the new MySQL source tarball and unpack it, say to mysql-5.1.38

• run these commands:

• Now do a normal merge from lp:maria-captains/maria/mysql-docs-merge-base into lp:maria

_{This page is licensed: CC BY-SA / Gnu FDL}

Note: This page is obsolete. The information is old, outdated, or otherwise currently incorrect. We are keeping the page for historical reasons only. Do not rely on the information in this article.

We merge TokuDB from Tokutek git repositories on GutHub:

• tokudb-engine

• ft-index

Just merge normally at release points (use tag names) and don't forget to update storage/tokudb/CMakeLists.txt, setting TOKUDB_VERSION correctly.

_{This page is licensed: CC BY-SA / Gnu FDL}

If you have a merge tree, you merge into MariaDB as follows:

1. MariaDB merge trees are in the mergetrees repository. Add it as a new remote:

1. Check out the branch you want to update and merge, for example:

1. delete everything in the branch

2. download the latest released source tarball, unpack it, copy files into the repository:

• for InnoDB-5.6: use the content of the storage/innobase/ of the latest MySQL 5.6 source release tarball.

• for performance schema 5.6: use storage/perfschema, include/mysql/psi, mysql-test/suite/perfschema, and mysql-test/suite/perfschema_stress from the latest MySQL 5.6 source release tarball.

1. Now git add ., git commit (use the tarball version as a comment), git push

2. merge this branch into MariaDB

3. Sometimes after a merge, some changes may be needed:

• for performance schema 5.6: update storage/perfschema/ha_perfschema.cc, plugin version under maria_declare_plugin.

• for InnoDB-5.6: update storage/innobase/include/univ.i, setting INNODB_VERSION_MAJOR, INNODB_VERSION_MINOR, INNODB_VERSION_BUGFIX to whatever MySQL version you were merging from.

_{This page is licensed: CC BY-SA / Gnu FDL}

Note: This page is obsolete. The information is old, outdated, or otherwise currently incorrect. We are keeping the page for historical reasons only. Do not rely on the information in this article.

Background

Percona used to maintain XtraDB as a patch series against the InnoDB plugin. This affected how we started merging XtraDB in.

Now Percona maintains a normal source repository on launchpad (lp:percona-server). But we continue to merge the old way to preserve the history of our changes.

Merging

There used to be a lp:percona-xtradb tree, that we were merging from as:

Now we have to maintain our own XtraDB-5.5 repository to merge from. It is lp:~maria-captains/maria/xtradb-mergetree-5.5. Follow the procedures as described in to merge from it.

_{This page is licensed: CC BY-SA / Gnu FDL}