pull -r $rev doesn't limit revisions converted

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Hudson wrote:
> Public bug reported:
>
> Demo:

Is this because you are trying to use incremental pull to get around
other issues? (bzr pull -r 100; bzr pull -r 200; etc)?

Certainly AIUI, I believe Jelmer has issues with some sources not
providing lookup ability. For example 'bzr-git', the git protocol
doesn't let you inspect the info, just pull the whole thing and inspect
it locally. (you can't walk the graph to determine what '-r -10' is.)

I don't know if bzr-hg suffers from the same problem. I don't know the
hg protocol that well.

(To say that, bzr-git and bzr-hg may always have to do a full fetch,
they may not have to do a full conversion.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuo1p0ACgkQJdeBCYSNAAMtDwCg0934Qt5h1AfGXwi7kGpqXcSW
oJkAoK9dCssAg/DVN7rT+vce0XxHiPcd
=ZEjX
-----END PGP SIGNATURE-----

On 24/03/10 03:56, John A Meinel wrote:
> Michael Hudson wrote:
>> Public bug reported:
>>
>> Demo:
>
> Is this because you are trying to use incremental pull to get around
> other issues?

That's what we're doing for git and svn now -- and the issues are
roughly: performance, memory leaks and resource utilization.

> (bzr pull -r 100; bzr pull -r 200; etc)?

But not quite like that :)

> Certainly AIUI, I believe Jelmer has issues with some sources not
> providing lookup ability. For example 'bzr-git', the git protocol
> doesn't let you inspect the info, just pull the whole thing and inspect
> it locally. (you can't walk the graph to determine what '-r -10' is.)
>
> I don't know if bzr-hg suffers from the same problem. I don't know the
> hg protocol that well.

That's not really the problem, I think. I think Jelmer thinks that we
always convert full branches (in the mercurial sense) even if the
revision requested is in the middle of a branch.

> (To say that, bzr-git and bzr-hg may always have to do a full fetch,
> they may not have to do a full conversion.)

Well, even if bzr-hg decides to convert all the revisions it receives
(which IMHO it shouldn't) it shouldn't set the branch tip to the wrong
thing!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Hudson wrote:
> On 24/03/10 03:56, John A Meinel wrote:
>> Michael Hudson wrote:
>>> Public bug reported:
>>>
>>> Demo:
>> Is this because you are trying to use incremental pull to get around
>> other issues?
>
> That's what we're doing for git and svn now -- and the issues are
> roughly: performance, memory leaks and resource utilization.
>
>> (bzr pull -r 100; bzr pull -r 200; etc)?
>
> But not quite like that :)
>
>> Certainly AIUI, I believe Jelmer has issues with some sources not
>> providing lookup ability. For example 'bzr-git', the git protocol
>> doesn't let you inspect the info, just pull the whole thing and inspect
>> it locally. (you can't walk the graph to determine what '-r -10' is.)
>>
>> I don't know if bzr-hg suffers from the same problem. I don't know the
>> hg protocol that well.
>
> That's not really the problem, I think. I think Jelmer thinks that we
> always convert full branches (in the mercurial sense) even if the
> revision requested is in the middle of a branch.
>
>> (To say that, bzr-git and bzr-hg may always have to do a full fetch,
>> they may not have to do a full conversion.)
>
> Well, even if bzr-hg decides to convert all the revisions it receives
> (which IMHO it shouldn't) it shouldn't set the branch tip to the wrong
> thing!
>

oh absolutely, I was mostly pointing out that 'bzr pull -r X' may not be
as efficient as you would like, because of limitations of the remote side.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkupVuMACgkQJdeBCYSNAAOBwQCg1OLlm3rk27dscKwJit7yfaLV
Z6wAoMvBdofmpNtt9EXixfgbAlrb2a8x
=bvV8
-----END PGP SIGNATURE-----

the branch tip is now set correctly. We still fetch too much data from Mercurial but that's a different (and nontrivial) problem.