Foreign branch infrastructure plans
ian.clatworthy at internode.on.net
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
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
* 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
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.
More information about the bazaar