Showing posts with label bazaar. Show all posts
Showing posts with label bazaar. Show all posts

Monday, October 05, 2015

MySQL-Sandbox 3.1.01 - First release after the change

I have released MySQL-Sandbox 3.1.01, which is the first release after the move to GitHub. While the changes are not so spectacular (it's a minor release, with mostly bug fixes), I am pleased to see that the move has started producing collaboration. Two of the changes were provided by Daniƫl van Eeden and Mark Leith, who have scratched some of their own itches by providing useful patches.

All in all, this period of working with GitHub has been liberating. Although Bazaar plays with the same principles of git, it lacks most of the tools and the know-how which characterizes git. Add to this that also my team has moved Tungsten Replicator to Github, and with that I found myself all of a sudden free of old revision control systems, and master of my own time.

Back to MySQL-Sandbox: while its enhancements may not amount to much, it helped me to discover several bugs in MySQL, some of which were addressed and solved quickly. So, I have had a deeper relationship with the community, with the experience of being at both ends of the collaboration ops.

The last notable piece of news about this release is that it has been tested with the latest and greatest available: a preview of MySQL 5.7.9 and the latest MariaDB 10.1.6. With this, I hope to witness a GA release of either flavor that does not break MySQL-Sandbox. We'll see!

Wednesday, March 17, 2010

Protocol, the GPL, and how Bazaar can help

Bazaar
Mark Callaghan asks Can a protocol be GPL?, after finding a disturbing comment in a source file:
Any re-implementations of this protocol must also be under GPL, unless one has got an license from MySQL AB stating otherwise.

I recall talking with one of the company lawyers about this matter, and he assured me that the GPL can't be used for a protocol, and that's why this notice was dropped from MySQL.com site a few years ago, even before the Sun acquisition.
This is thus an embarrassing piece of ancient history (which will hopefully be removed soon) that has been in our files for long time. For how long?
If we get the source trees from the public bazaar repository, we don't get a good answer.

$ bzr annotate --long --all sql/net_serv.cc | head -n 24 |tail -n 9
2476.648.3 cmiller@xxxxx 20071011 | /**
2476.648.3 cmiller@xxxxx 20071011 | @file
2476.648.3 cmiller@xxxxx 20071011 |
1616.1722.3 joerg@xxxxx 20050307 | This file is the net layer API for the MySQL client/server protocol,
1616.1722.3 joerg@xxxxx 20050307 | which is a tightly coupled, proprietary protocol owned by MySQL AB.
2476.648.3 cmiller@xxxxx 20071011 | @note
1616.1722.3 joerg@xxxxx 20050307 | Any re-implementations of this protocol must also be under GPL
1616.1722.3 joerg@xxxxx 20050307 | unless one has got an license from MySQL AB stating otherwise.
1616.1722.3 joerg@xxxxx 20050307 |

Inspecting revision 1616.1722.3, we learn that it was just a merge. This thing was much older. A comment in Mark's blog from Venu Anuganti put me on the right track. He was a MySQL employee in 2003, and thus I needed to find older annotations.
A few years ago I showed how you could get back in time using Bazaar .
Using this technique, I resuscitated MySQL 4.1.2

$ bzr branch -r tag:mysql-4.1.2 lp:mysql-server/5.1 branch4.1.2
$ cd branch4.1.2
$ bzr annotate --long --all sql/net_serv.cc | head -n 24 |tail -n 9
2 bk@xxxxxxx 20000731 |
1098.3.1 monty@xxxx 20020723 | /*
1538.19.1 monty@xxxx 20030604 | This file is the net layer API for the MySQL client/server protocol,
1538.19.1 monty@xxxx 20030604 | which is a tightly coupled, proprietary protocol owned by MySQL AB.
1538.19.1 monty@xxxx 20030604 | Any re-implementations of this protocol must also be under GPL
1538.19.1 monty@xxxx 20030604 | unless one has got an license from MySQL AB stating otherwise.
1538.19.1 monty@xxxx 20030604 | */
1538.19.1 monty@xxxx 20030604 |
1538.19.1 monty@xxxx 20030604 | /*

$bzr log -r 1538.19.1
------------------------------------------------------------
revno: 1538.19.1
committer: monty@xxxx
timestamp: Wed 2003-06-04 18:28:51 +0300

So, this looks like a commit, not a merge, and thus we have found the origin of the offending message.
However, there is a problem.
In a comment on a recent Brian's blog post, Monty said
"I have never said or claimed that the GPL affects you over the protocol."
I am sure there is a reason for this quote, but unfortunately Bazaar doesn't have an answer.

Tuesday, September 16, 2008

Advanced Bazaar for MySQL developers


Bazaar Sakila

Guilhem Bichot has written an excellent article on Advanced Bazaar for MySQL Developers. In addition of showing the most common Bazaar operations for developers, Guilhem shows how to create a new feature and submit it for review to MySQL.

The article is an practical introduction to Bazaar's advanced features. After the basics, magnificently covered by Daniel Fischer a few weeks ago, this article explains how to perform high level development operations with Bazaar.
Bravo Guilhem!

Sunday, September 14, 2008

Launchpad improvements




Launchpad, the development framework created by Canonical, is under constant development.
If you have never used it, have a look at Jay's getting started and code management articles about it. If you know it already, you may be pleased to know that Launchpad has a countinuous edge beta testing program that anyone can try.

If you are getting curious, then let me tell you that there are actually three testing environments:
edge, which is the beta testing environment. You get into if by adding edge before launchpad.net in every URL. If you subscribe to the beta testing program and are accepted, every time you connect to launchpad you are redirected to the edge environment, which uses the latest beta interface and the production database. Every change you make with the edge interface is permanent.
staging, which is a non permanent testing environment. It uses the beta interface, and a copy of the production environment, which is replaced at regular intervals. Here you can try daring operations, without risking your valuable production data.
dogfood has rules similar to staging, but the level of experimental is even higher. Its contents may change without notice.
Using the edge environment, you will notice an enhanced interface (a detail here) and some hidden improvements.

One of the recent improvements is a bug that I asked the Canonical developers to fix, because it was affecting the usability of Launchpad as a development framework. Bug#66344 is about the graphical display of a blueprint dependency tree. In the old application, when you had more than a dozen dependencies, you got a cramped display like this one.

Absolutely unreadable. But if you get the same page through edge, you get this one:

The resolution of this bug is very important for my team campaign of promoting Launchpad. At MySQL developers meeting, which will start in Riga in the next days, we will show the goodies of Launchpad to anyone willing to listen, and since blueprint management are a vital component in every development effort, this recent improvement will make things look better for Launchpad beginners. Thanks to Joey Stanford and Christian Reis for speeding up matters with this bug!
Happy coding!

Thursday, June 19, 2008

From Bazaar to Sandbox in 5 moves


Now that MySQL has switched its development to Bazaar, we can play a bit with the new tools. One thing that I have tried immediately upon adoption of the new RCS is to create a test bench for multiple MySQL versions by combining Bazaar and MySQL Sandbox.

If you are into bleeding edge testing, you may like to know how to get a new MySQL server up and running in a sandbox from a source tree.

First move - make the repository

This is a zero time consuming move, and you will have to do this only once. But this move will save you heaps of time in future. By creating a shared repository, you are telling Bazaar to avoid redundant copies of files (actually Bazaar is much smarter than this, but as a simple explanation it will do).
$ bzr init-repo shared
$ cd shared/

Second move - get the source

Now we're ready to get the first copy of our source. The first branch we get is the current tree, 5.1. Depending on the speed of your network connection, it will take between 20 and 40 minutes.
$ time bzr branch lp:mysql-server/5.1  51
lp stands for launchpad. mysql-server is the project name, and 5.1 is the version. 51 is the directory we are creating on the local disk. You can call it whatever you want. I prefer short names.

This operation may be tricky. The current Bazaar client (1.5) is not verbose. It may actually appear to be doing nothing for very long time. It is actually importing code. Don't be discouraged and bear with me on this. It will pay off in the end. After a while you will see a progress bar and eventually it will display the result.
Branched 2655 revision(s).                                                                                                   
real 19m14.110s
user 7m22.883s
sys 1m21.372s
In my laptop, it took less than 20 minutes, but it could be much slower, depending on connection type and intensity of net traffic.

Let's have a look at the size of what we have downloaded. The hidden directory .bzr contains the biggest chunk.
$ du -sh .bzr/ */
498M .bzr/
129M 51/
Now for the juicy part. We want to branch also MySQL 5.0. You may be ready for yet another 20 minutes and 600 more MB of data to be added, but you are in for a good surprise:
$ time bzr branch lp:mysql-server/5.0 50
Branched 2634 revision(s).
real 0m42.205s
user 0m28.100s
sys 0m4.757s
Less than one minute! And what about storage?
$ du -sh .bzr/ */
498M .bzr/
100M 50/
129M 51/
As you see, the new code added just the difference between 5.1 and 5.0, so it did not even had to get it from the net because it mostly got the previous version from the internal history (we'll come back to this point in a later post).
A similar experience awaits you when branching the newest version, 6.0. A bit slower than 5.0 (because it has to get something more from the net), but still quite fast compared to the full tree we got in the first run.
$ time bzr branch lp:mysql-server/6.0 60
Branched 2664 revision(s).
real 4m45.383s
user 1m39.727s
sys 0m20.776s
$ du -sh .bzr/ */
566M .bzr/
100M 50/
129M 51/
146M 60/

Third move - export the code

We have now on disk the code for three versions. We could just go inside each directory and build it, but that would not be clean. So in this move we just export the code to a build directory that we create for this task.
$ mkdir ~/install/build
$ ls
50 51 60
Using a shell loop, we export each tree to a build directory. It takes about 30 seconds for each tree.
$ for R in 50 51 60 ; do echo $R ; cd $R ; bzr export ~/install/build/$R ; cd .. ; done
50
51
60

Fourth move - build the code

We are finally ready to build. Each build can take quite long, depending on your box. In my laptop, it takes about 40 minutes per build.

In the ./BUILD directory in each source tree there are several building scripts. Choose the one that suits your purposes, eventually disabling the parts that you don't need (e.g. cluster).
$ cd ~/install/build
$ for R in 50 51 60 ; do \
cd $R ; \
./BUILD/your_favorite_script && ./scripts/make_binary_distribution ; \
cd .. ; \
done
After each build, this loop runs make_binary_distribution, which creates a binary tarball, right what you need for MySQL Sandbox.

Fifth move - sandbox it!

Now, let's use our favorite installation tool to use these new binaries.

Download the sandbox. Make sure that you got at least version 1.21.
$ export SANDBOX_HOME=$HOME/sandboxes
$ cd ~/install/mysql_sandbox-1.21
For each version, you invoke the sandbox installer as
./express_install full/path/to/tarball_name.tar.gz
Here we go
$ ./express_install.pl ~/install/build/50/mysql-5.0.66-darwin9.3.0-i386.tar.gz
unpacking /Users/gmax/install/build/50/mysql-5.0.66-darwin9.3.0-i386.tar.gz
Executing ./install.pl --basedir=/Users/gmax/install/build/50/5.0.66 \
--sandbox_directory=msb_5_0_66 \
--install_version=5.0 \
--sandbox_port=5066 \
--no_ver_after_name
The MySQL Sandbox, version 1.21 09-Jun-2008
(C) 2006,2007,2008 Giuseppe Maxia, MySQL AB
installing with the following parameters:
home_directory = /Users/gmax/sandboxes
sandbox_directory = msb_5_0_66
sandbox_port = 5066
datadir_from = script
install_version = 5.0
basedir = /Users/gmax/install/build/50/5.0.66
[...]
loading grants
sandbox server started
installation options saved to current_options.conf.
To repeat this installation with the same options,
use ./install.pl --conf_file=current_options.conf
----------------------------------------
Your sandbox server was installed in /Users/gmax/sandboxes/msb_5_0_66

$ ./express_install.pl ~/install/build/51/mysql-5.1.26-rc-darwin9.3.0-i386.tar.gz
unpacking /Users/gmax/install/build/51/mysql-5.1.26-rc-darwin9.3.0-i386.tar.gz
Executing ./install.pl --basedir=/Users/gmax/install/build/51/5.1.26 \
--sandbox_directory=msb_5_1_26 \
--install_version=5.1 \
--sandbox_port=5126 \
--no_ver_after_name
The MySQL Sandbox, version 1.21 09-Jun-2008
(C) 2006,2007,2008 Giuseppe Maxia, MySQL AB
installing with the following parameters:
home_directory = /Users/gmax/sandboxes
sandbox_directory = msb_5_1_26
sandbox_port = 5126
datadir_from = script
install_version = 5.1
basedir = /Users/gmax/install/build/51/5.1.26
my_file =
[ ... ]
sandbox server started
installation options saved to current_options.conf.
To repeat this installation with the same options,
use ./install.pl --conf_file=current_options.conf
----------------------------------------
Your sandbox server was installed in /Users/gmax/sandboxes/msb_5_1_26
$ ./express_install.pl ~/install/build/60/mysql-6.0.6-alpha-darwin9.3.0-i386.tar.gz
unpacking /Users/gmax/install/build/60/mysql-6.0.6-alpha-darwin9.3.0-i386.tar.gz
Executing ./install.pl --basedir=/Users/gmax/install/build/60/6.0.6 \
--sandbox_directory=msb_6_0_6 \
--install_version=6.0 \
--sandbox_port=6060 \
--no_ver_after_name
The MySQL Sandbox, version 1.21 09-Jun-2008
(C) 2006,2007,2008 Giuseppe Maxia, MySQL AB
installing with the following parameters:
home_directory = /Users/gmax/sandboxes
sandbox_directory = msb_6_0_6
sandbox_port = 6060
datadir_from = script
install_version = 6.0
basedir = /Users/gmax/install/build/60/6.0.6
[ ... ]
sandbox server started
installation options saved to current_options.conf.
To repeat this installation with the same options,
use ./install.pl --conf_file=current_options.conf
----------------------------------------
Your sandbox server was installed in /Users/gmax/sandboxes/msb_6_0_6
At the end of the exercise, you have three sandboxes with the three major MySQL versions, ready to use. Enjoy!

Sunday, June 15, 2008

MySQL Sandbox 1.22 and the joys of developing on launchpad

I have recently moved MySQL Sandbox to launchpad and Bazaar.
MySQL Sandboxlaunchpad

Working with Launchpad is really a joy. It is much more than providing a web interface to Bazaar version control. It also includes provisions for bug reporting and handling, writing blueprints for your roadmap, creating distribution files, and manage your packages if you want to release them in Ubuntu.
Using the above tools, I implemented a couple of new features to MySQL Sandbox, and I started to work on a roadmap for the next version, which is now taking shape.
The latest version (1.22) includes the ability of using a default option file ($HOME/.msandboxrc), a safer usage of the "--force" option, and several bug fixes.

Tuesday, June 10, 2008

MySQL Sandbox 1.21 - matrioska and launchpad

MySQL Sandbox has moved to a new home. It is now hosted at Launchpad, a friendly environment where developers can work together.

What's new with MySQL Sandbox? The matrioskas in the image are a clue. Version 1.21 introduces the concept of SANDBOX_HOME, which previously was only a path under which store the sandboxes. With time, when I was using more and more sandboxes, I realized that I wanted to take control of all the sandboxes at once, and issue global commands to all of them.
Starting with this version, the sandbox installer recognizes an environmental variable named $SANDBOX_HOME, and builds the sandboxes under that path.
In addition to grouping all the sandboxes in a place, the installer creates a few scripts that allow you to take control of all the active sandboxes.
Let's say that you have a single sandbox of MySQL 5.0.62, a replication system of 7 5.1.24 servers, and a multiple installation of 5 6.0.5 servers.
Prior to this version, if you wanted to stop each sandbox, you should have to enter each sandbox directory and run "./stop" or "./stop_all". With the sandbox outer container, you just have to run "./stop_all" from one place.
You can also execute the same command in each server in all your sandboxes, by means of the "./use_all" script.
If you want to learn more, on Thursday, June 12, 2008 at 15:00 CEST, I will host a MySQL University session on this very subject.