Foreign branch infrastructure plans

[Martin Pool]

That's a very nice list.


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

What do you mean by 'upstream revision'?

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

Right, so presumably returning some kind of object that encapsulates
the rules, rather than just the file contents.

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

Yes, I think they're meant to be just part of the implementation and

> Anything I'm missing?

It's only a bit related but I'd like to move more towards having clean
hierarchies for the main components.  I'm thinking we should have one
base which only defines the interface and is purely abstract, and then
a subclass that provides 'reasonable defaults' for methods (like
"return False" for supports_foo()), or building more complex methods
on more primitive ones.  At the moment they're a bit mixed up.

-- 
Martin <http://launchpad.net/~mbp/>