Allow merge-in of bzr branches

Thank you for the suggestion.

Just to check understanding of the use-case : on such setups, you have commits that aren't in the remote branch and you want to remerge the remote branch each time you run 'bin/buildout'

I suppose this implies that the end local result is actually not shared with other systems.
For practices at Anybox, which involve lots of continuous integration based on that same buildout configuration, we'd probably want to share the resulting branch (so that builders can grab it). Therefore, I think we would not have this use-case so directly (we've been avoiding bzr as much as possible for its poor performance and reliability in automated environments).

That being said, I guess this feature would be a nice path toward full automation of a derivative distribution : imagine a CI build that would run such a configuration, automatically merging upstream, running the tests and ending with an automated push. I could probably introduce that in our buildbot configurations in an hour of work time. And that's something I'd love to have very soon. It would alleviate a lot the maintainance burden of a derivative distribution such as OCB.

Maybe this can help for advanced CI practices, such as gated commit (where the CI robot takes care of merging developer branches in the trunk).

This raises a few more practical questions, but I think I'll post them on your merge request.

As a side remark, the first version of the git support did behave like this : it used to issue 'git pull' commands instead of the proper 'fetch' + 'checkout' combination. That was corrected, I believe, by Laurent Mignon, but we could easily restore it optionnaly.

In Mercurial, the same result would be achieved by issueing 'hg merge' + 'hg commit' after the retrieval part ('pull' + 'update')

Forget SVN ;-)

Hi Georges,

you are right about the use case, but yours is a valid one too.

> I suppose this implies that the end local result is actually not shared with other systems.

Well it could if you pin the revisions of the main branches and the merge-ins.

Offtopic: when someone brings up the performance of bzr as problematic, I always feel obliged to say that using a (symlink to a) shared repository has solved all issues that we ever experienced.

Thanks for your response!

Now that I've done the housekeeping work, I'm targetting this to 1.9.0

Merged a few weeks ago