> 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
>
Except hg can't have ghosts...
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> 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
>
Except hg can't have ghosts...
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk2 UBxwACgkQJdeBCY SNAAP6lgCguZhF6 +NP6jwM/ aGHnNFipZZg 2CW/FhbjjqnFkI0 l2
pNgAoItbHjf3jiv
=NGEH
-----END PGP SIGNATURE-----