2

I'm new to Bazaar, coming to it from a background of Subversion and git. I thought I had a working grasp of some basic concepts, but have already hit a stumbling block in my first major commit.

The project is hosted on Launchpad. I created a local branch ("working") with bzr branch. I made changes, added new files, renamed others. In the interim another person on the team committed and pushed their changes. At this point the commit history looked something like this:

3. Team Member A
2. Me (trivial commit of .bzrignore)
1. Original commit

This morning I bzr commit my changes locally. The commit number was reported as 3, which I assumed (wrongly) would be reconciled when I sync'd with the server. When I did a bzr pull I got this message:

Using saved parent location: bzr+ssh://bazaar.launchpad.net/...
bzr: ERROR: These branches have diverged. Use the missing command to see how.
Use the merge command to reconcile them.

I did bzr merge. No conflicts were discovered but three files were left as modified in my local branch. I inspected and committed those with a comment, which was reported to me as commit 4. Then I did a bzr push, which reported no errors.

Now the commit history (bzr log --include-merges) looks like this:

4.    My merge commit
2.1.1 Team Member A
3.    My commit this morning
2.    My .bzrignore commit
1.    Original commit

There's a high desire here to keep the trunk line serialized and avoid these merge bubbles. (Annoyingly, Launchpad doesn't display the 2.1.1 commit, making it look like I overwrote it.) What is the best workflow in this situation to avoid these bubbles? Should I have pulled first? I'm wary of having to merge other people's code into my local uncommitted changes.

In addition, although rebase is commonly used in git, it appears it's not generally approved of in the Bazaar world. If we can avoid using the bzr-rebase plugin, that would be great.

Jim Nelson
  • 1,688
  • 3
  • 15
  • 27
  • In addition to the answers below, you can also prevent this problem in the future by setting the append_revisions_only option in the config for your branch. With that set, it will not allow the commit to proceed when it would re-arrange the order of revisions like your example. – dOxxx Dec 05 '11 at 22:05
  • Yes, I saw an answer suggesting this after posting mine: http://stackoverflow.com/questions/5413602/monotonically-increasing-bazaar-trunk-revision-numbers However, we're more interested in Bazaar best practices than tweaks to fit our own ideas of what's "right". – Jim Nelson Dec 07 '11 at 18:03
  • There's actually some debate as to whether append_revisions_only should be turned on by default, since the off behaviour nearly always surprises users. So don't think of it as a hack or non-standard behaviour. It's more like security that you don't get surprised by this again in the future. – dOxxx Dec 07 '11 at 21:19

1 Answers1

1

One way to have a cleaner mainline history would be to do your work in a separate feature branch, while maintaining a mirror of the mainline branch. I'm assuming branches with working trees here, but you could use treeless branches and a checkout to save disk space.

// setup the mirror branch
cd <mirror directory>
bzr pull <mainline>

// setup a feature branch
cd <feature directory>
bzr branch <mirror directory> .

// work on your feature branch
bzr commit -m "Did some work"
...
bzr commit -m "Did some more work"

// ready to commit your feature
cd <mirror directory>
bzr pull
bzr merge <feature directory>

// your integration testing is done
bzr commit -m "My shiny feature"
bzr push
Adam Glauser
  • 877
  • 4
  • 13
  • An easy way to do this is to use the bzr-colo plugin, which gives you "colocated" branches in the same working tree. – dOxxx Dec 05 '11 at 22:02
  • Thanks for the concise answer. You've verified the suspicion that I had, that we just need to accept the Bazaar Way of doing things. Also, I was pointed to this web page which suggests something similar to your answer and offers some justifications for doing it this way: http://doc.bazaar.canonical.com/bzr.2.4/en/user-guide/zen.html#hierarchical-history-is-good – Jim Nelson Dec 07 '11 at 18:07