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

[Martin Pool]

2009/11/23 Ian Clatworthy <ian.clatworthy at canonical.com>:
> 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?

The PoEAA definition for "gateway" I can find
<http://martinfowler.com/eaaCatalog/gateway.html> seems to cover
something like bzr-git, whereas you seem to mean it to mean something
else: a lower-fidelity gateway that emphasizes simplicity and
reliability(?) over running on demand and giving perfect round
tripping?  I don't know if that pattern has a name but it is worth
remembering when you're trying to translate between foreign systems.

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

It's a valid option; I think we should at least clearly document it.

In udd and Launchpad I made a similar point: perfect round tripping
shouldn't be a goal in itself, because it's likely to be expensive and
elusive.  Instead, the point is to let people bring in the patches
they need and to get the data out somehow - if patches are enough,
send patches.

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