Foreign branch infrastructure plans

[Ian Clatworthy]

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:

Jelmer,

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
http://bazaar-vcs.org/BzrFileCopies 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
assuming:

* 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

  .bzr/repository/foreign-vcs/rev-id-map

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.