Comment 17 for bug 309682

On Wed, 2011-03-30 at 14:25 +0000, John A Meinel wrote:
> On 3/30/2011 4:01 PM, Jelmer Vernooij wrote:
> > This is fairly tricky to do efficiently with Mercurial; Mercurial itself
> > just hides tags that point at revisions not in the tip ancestry.
> >
> > We only find out the tags at the point that the tip contents have been
> > fetched, so we'd have to do completely new pulls for the revisions that
> > are missing.
> >
> > ** Changed in: bzr-hg
> > Milestone: 0.2 => None
> >
>
> It seems like you could just do an elongated fetch. So you first fetch
> the current tip, then after you have it, you see what other data you
> need, and send that along.
>
> Certainly we already do that in bzr for fetching inventories chaining to
> chk_bytes chaining to file texts.
>
> I don't know the bzr-hg internals, but conceptually it doesn't seem like
> we would have to know all the tags up front.
It's trivial to do it like that, it's doing it in a way that doesn't
hurt performance that worries me. Doing a second fetch requires new
analysis of what revisions are present locally versus remotely and it
might require a new http connection to be opened.

If there is a tag that points at a ghost remotely then each fetch from
the remote host will require an extra graph inspection and fetch we
don't do at the moment.

Cheers,

Jelmer