bzr-git, the git map, fetching revisions, and being very slow

[Ian Clatworthy]

Russel Winder wrote:

> The
> user goal is to interact with a Git repository.  Current options are use
> a Git clone or use a Bazaar branch. Major factors here are branch model
> and speed.

Having spent most of my career working on very large 24x7
enterprise-scale systems, I strongly believe we're under-utilising the
"gateway" architecture for interacting with foreign systems. I wonder
how many of the reasons are technical and how many are social?

I truly think bzr-svn, bzr-git and bzr-hg are awesome tools and they
have a *huge* role for Bazaar going forward. OTOH, like any wrapper
technology:

1. Performance will (nearly) always be below the thing being wrapped.
2. User expectations are (nearly) always well above what's possible.
3. Initial excitement will give way to dissatisfaction over time.

For large projects where the wrapper architecture doesn't scale, I feel
we should be recommending a "gateway" architecture, i.e. converting from
a git repo to a bzr one and sending back patches in 'git' format (mail
patch sets). Ditto for hg and returning bundles.

You give two options for interacting with git but there's a third option
as well: setup & maintain a bzr mirror using
git-fast-export+bzr-fast-import. The "setup" bit is polished reasonably
well now though the "maintain" bit is currently well below the
ease-of-use of bzr-git. OTOH, it's pretty fast and will get faster (when
I land some of jam's patches). Maybe fastimport could record the
information dpush needed as well?

Maybe fastimport isn't the best way for implementing a gateway. Either
way, we ought to recommend that *architecture* far more often. There's
nothing stopping us polishing up svn-import, git-import and hg-import to
make adopting that architecture easier. Or is there?

Why don't we? Is it a simple matter of documentation? Or do we need to
change our "group-think" first?

Ian C.