Hi serg, Thank you for your comment. I will clean my repo at some later time follow your advice. :) Sincerely, Shuang On Jun 18, 2013, at 4:51 PM, Sergei Golubchik <serg@mariadb.org> wrote:

Hi, QIU Shuang!

Just to answer the bzr part:

On Jun 16, QIU Shuang wrote:

...

The first one is about the private repo and bazaar (I'm a git guy and have little experience working with bazaar). In order to make some demonstrated progress, I push my local update to the private repo each time I create a new commit. It seems the commit number is global (see the screen shot of my private repo history below).

Recent revisions 3796. By Shuang Qiu 20 hours ago prototype with GSSAPI enabled 3795. By Shuang Qiu on 2013-06-15 Kerberos plugin prototype with raw krb5 API 3794. By Shuang Qiu on 2013-06-13 doodle 3793. By Michael Widenius on 2013-06-11 Fixed tests that failed on 32 bit because of my earlier fixes of 32 bit limits. 3792. By Sergei on 2013-06-07 MDEV-4468 Assertion `error != 0' fails or timeout occurs on select from a FEDERATED table which points at a non-existent table

I'm afraid that my commits may pollute the code base. So the question is that will others (e.g. Sergei since commit 3792) see my changes next time he gets local branch updated. Is it the best practice to use bazaar like this (push after each commit)?

Don't worry about it. Revision numbers in bzr aren't stable, during a merge they might be renumbered (*). Revision ids are stable and unique, but they look like

sergii@pisem.net-20130607133513-p27s1bg8gt0amkiw

(this is for my commit with revno 3792 above). Think of revision numbers as of convenient shortcuts that help to avoid typing and that are easy to remember. But don't use them for long-term references or something.

And no, I won't see your changes when I pull from 5.5. Not unless I pull from your repository.

Regards, Sergei

[1]. Details. Example. Say you have a repo with only one changeset. It has revno 1. You've branched. And you've made changes and committed something in both branches, independently. Every branch has now two changesets. Changeset 1 (it's the same in both, save revid), and Changeset 2 (revno is the same, revid is different). Now if you merge the second branch into the first, the changeset 2 of the second branch will be renumbered, it'll get revno 1.1 (but its revid won't change). The history will look like (Changeset 3 is the merge changeset):

1 | \ 2 1.1 | / 3