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

[Ian Clatworthy]

Martin Pool wrote:
> 2009/11/23 Ian Clatworthy <ian.clatworthy at canonical.com>:
>> Russel Winder wrote:
>>
>>> The
>>> user goal is to interact with a Git repository.

>> 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 was being lazy with my terminology and hoping no-one would pull me up
on it. Damn. :-) By "gateway", I meant that we should keep the 2 systems
separate rather than aiming for fast, transparent interaction. To be
stricter about the pattern naming, I guess I'm arguing for
http://www.eaipatterns.com/FileTransferIntegration.html over
http://martinfowler.com/eaaCatalog/dataMapper.html.

My point was that high performing systems are optimised so that the code
is heavily tuned to the underlying data. Just look at how many code
changes were necessary in the higher layers of bzrlib when we switched
from knits to packs and again from packs to chk. Dynamically interacting
with a foreign repository format is a bit like us just changing the
format and (mostly) ignoring the higher layers.

At any given time, bzrlib over bzr's repository format is likely to be
much quicker than bzrlib over the repository format of another tool. For
small projects, it doesn't matter. For medium-to-large projects, bzrlib
over git/hg/svn data will be *noticeably* slower than git over git (and
that's what end users will compare us with). That's no reflection of
Jelmer's great work - it's just the nature of the problem.

Ian C.