Foreign branch infrastructure plans

Ian Clatworthy ian.clatworthy at
Sat Mar 14 01:58:08 GMT 2009

Jelmer Vernooij wrote:
> So, over the past year or so I've slowly been providing patches
> to improve the infrastructure of Bazaar to support foreign branches. 
> I thought I would give an update as to what (little) there is
> left to do:


Thanks for sending this to this list. I'm yet to digest what you've
done, let alone what's remaining, but I want to make some quick
comments for you to think about. Apologies if those comments appear
dumb - I certainly haven't thought them though in any real depth yet!

>  * Integrate "bzr dpush" so it can be used by other foreign branch
>    plugins. This patch is currently waiting for review.

Can we use a more meaningful name than dpush? dpush is fine as an
alias but it isn't very discoverable unless you know that it's the
command you want.

>  * Bzr info needs to be extendable so foreign formats can show extra
>    information. E.g. "bzr info" on a svn repository should show the
>    repository's UUID.

I'd also like to see us make more of an effort not to lose/hide
semantic data available in foreign systems. In particular, I'd like
us to retain/display file copies in our data formats, even if we
don't have the UI for defining copies yet. I've updated in recent days with an outline
of potential schema changes supporting this (together with some
thoughts on how to resolve some of the UI interaction issues).

> Anything I'm missing?

I'd like foreign branch support and fast-imported repositories to
play together more nicely. For example, I'd like users to be able
to use fast-import to generate a mirror repository on which dpush
could be used. I could be wrong but I think fast-import could
save the foreign-rev-id -> bazaar rev-id mapping quite easily

* xxx-fast-export saves the foreign-rev-id -> fast-import-mark mapping
* bzr-fast-import saves the fast-import-mark -> bzr-rev-id mapping.

I could easily combine the two to generate a mapping in


say. What other mappings does dpush need? One for file-ids as well?

FWIW, I feel it would be uber-nice to have foreign-vcs mapping
metadata defined in a generic way and stored in a defined location
like .bzr/repository/foreign-vcs. It ought to be possible to
generate it *after* the fact by comparing a bzr repository with
a foreign repository, rather than only at xxx-import time. And
I've never been a big fan of embedding the data in (potentially
dozens of) special rev-id namespaces. Among other reasons, it means
that repository size depends on how compression-efficient the rev-id
scheme is.

Looking at the big picture from a high level, I honestly feel that
the preferred model we ought to encourage is:

1. Generate a Bazaar mirror of the foreign repository/branches.
2. Bazaar users should treat that as *the* master branch.
3. Hooks should be used to keep that master in sync with the foreign master.

is preferable to the model of:

1. Each user runs import to create their own mirror.
2. Different users can merge with each other *if and only if* exactly the
   same deterministic rev-id (and file-id?) mapping algorithm is used.

In my limited experience in this area, the latter approach is useful
for small projects but doesn't scale well in terms of:

* ongoing maintenance of the mirroring
* workflow flexibility (e.g. putting PQM on the Bazaar master branch)
* performance in general.

My 2c,
Ian C.

More information about the bazaar mailing list