NdbBindings:Develop
Development of the NDB/Bindings is managed on Launchpad using Bazaar. The following is a walkthrough of how to get started working on the codebase.
Bazaar is a distributed revision control system. This means, amongst other things, that it's designed to be pretty useful even if you're not connected to everything. All of the basic operations work on branches of the code. When you make a branch of a published code tree, your local branch is no more or less official than the published one, from a technical perspective.
As you work and start making multiple local branches to work on different ideas, that many copies of the complete revision history can get, well, bulky. So I always create a local "repository" to work it, which shares the changeset history of multiple branches. Enough talking.
Assuming that I have a dir in my home dir called src that I do all of my work in, first I'm going to make a local repository for the NDB/Bindings
cd ~/src bzr init-repo ndb-bindings
Now, we want to grab a copy of the source
cd ndb-bindings bzr branch http://code.launchpad.net/~ndb-bindings/ndb-bindings/trunk
And you should see a dir: trunk. Exciting, isn't it. Now we don't actually want to work directly in the mainline, so let's make a branch to play around in.
bzr branch trunk work
Now you've got two branches, although you should have noticed that the second branching went quite quickly. This is because we're in the repository, and it didn't have to copy all of those revisions... clever, eh?
Now let's get to work in the code.
cd work ./autogen.sh ./configure
The tree should be all set to go. The configure script will configure all of the languages, but you certainly don't have to build them all. Let's say we're going to work on the java code. Now we're all set to go in to the java dir:
cd java make
And everything should go swimmingly. (If it doesn't, please file a bug at http://bugs.mysql.com) Of course, we're bound to find something and to fix it even.
# edit some files bzr commit
This commits to the local branch. Notice you didn't have to get permission here. You can repeat this process as many times as you like until you have things in the state you want them. When you think you're ready to send them upstream, there's two ways to go. You can publish your working branch on launchpad yourself:
bzr push sftp://myuser@bazaar.launchpad.net/~myuser/ndb-bindings/work
And then tell the ndb-bindings@lists.mysql.com that you have changes in that branch and let us pull them and merge them in. (Might be good idea to do anyway if this might be an ongoing branch you're working on) Or, you can do the merge work yourself and send us a nice bundle
cd ~/src/ndb-bindings/trunk # changing into the mainline branch here
bzr pull # get any changes up on the server
bzr pull ../work # pulls over the changes you've made in your branch
# OR - if the branches have diverged because of upstream activity
bzr merge ../work
Now you have a modified local copy. (Why bother with all of this? Why not just edit in the trunk branch - I'll get to that in a second, I promise)
bzr commit # in case you had to merge things in, they merges will need to be commited here bzr bundle-revisions > ../my.changes.1.revbundle # you don't have upstream write access yet.
And then email ~/src/ndb-bindings/my.changes.1.revbundle to ndb-bindings@lists.mysql.com. When we apply the revision bundle, it also applies changeset information, so you don't have to worry about bzr trying to doubly apply your patches next time you update from upstream.
So, why all the shenanigans? Why not just edit in the trunk branch directly?
Consider if there had been tons of work in your branch, and tons of work by other people upstream. Maybe you were hacking disconnected for a week. Who knows - I guess it could happen. Now it's time to merge stuff in. So, in the trunk branch, you do
bzr merge http://code.launchpad.net/~ndb-bindings/ndb-bindings/trunk
Bazaar remembers where you're working from, but just for the sake of the example, this is what you would do. Now, suppose there are some crazy conflicts and in the middle of resolving them you realize "EGADS! I've screwed it all up! I want to try again!" NOW what? What do you revert to?
In the earlier version, if you have errors in the merge step, you can just delete the trunk dir, re-branch trunk and try the merge again.