Foreign branch infrastructure plans

[Jelmer Vernooij]

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:

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

 * InterBranchToBzrDir. This controls the creation of a branch in an
   existing BzrDir based on another branch. Used by "bzr push" and
   "bzr branch". This is required so we can get rid of "bzr svn-push"
   and have that functionality integrated in "bzr push". I also have a
   patch for this, and the required changes for this are in bzr-svn, I
   just haven't submitted it yet.

 * InterBranch.pull(), InterBranch.push(). Being able to override these 
   methods is not strictly necessary but if it's possible foreign
   branch plugins can do some things slightly faster. For example,
   bzr-svn wouldn't have to look at the full ancestry for tags, and
   wouldn't have to look (potentially) at the full lhs history for the
   revno of the latest revision in the branch.

   It also means we could do tricks like automatically pull using the
   "mapping" of the target (native bzr) branch rather than the latest
   available "mapping", and avoid giving users confusing
   DivergedBranches errors. This would avoid the need for "bzr
   svn-upgrade" when you're just mirrorring a branch.

 * 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.

 * Converter.register_optimiser().  It should be possible to provide custom 
   Converters, instead of having the Converter be provided by the target 
   format. "bzr upgrade" isn't possible in foreign branches without this change,
   since the current Converters don't deal with foreign branches well,
   and they can't be overridden.

Also, there are some things that would be nice to fix, but I'm not
quite clear on the precise implementation:

 * Some sort of way to override what upstream revision to use in 
   "bzr merge" if none was specified. This would have to pick the
   right mapping to use for foreign branches. 

 * Tree should have a .get_ignores() method that can return the
   ignores independent of how they are stored. This is necessary so
   .bzrignore can end up in svn:ignore or .gitignore

 * It would still be nice to have "lazy" revision aliases so we don't
   have to determine the canonical revision id until we're comparing
   revision ids. Alternatively, it may be possible to have a Graph
   implementation that internally uses tuples with foreign revision ids and 
   mappings and get some of the same benefits, I'm not sure.

 * Stacking is very focussed around the bzr data formats right now, it
   would be nice if it could optionally not go via VersionedFiles for
   inventories, revisions and signatures if the formats were
   incompatible.

Anything I'm missing?

Cheers,

Jelmer

--