[Gnu-arch-users] [BUG] Avoiding ancestor scan during get with revision library

[Tom Lord]

    > From: Richard Curnow <address@hidden>

    > Supposing I have a revision library set up, and I do a get on a remote
    > http:// archive to do an initial checkout.  There are several hundred
    > patches between the import revision and the patchlevel I'm getting,
    > across several branches/versions, all in the same remote archive.  The
    > patchlevel I'm getting actually has a cacherev in the archive.


    > None of the ancestors are present in my revision library, and (at least
    > for now), I've no interest in any of them being added to it.  I
    > literally want only the working copy, + a clean version of it put into
    > my revision library.

    > (If I ever want one of the ancestors, I'm totally prepared to take the
    > hit that the revlib's hard-linking will become sub-optimal).

    > When I do the 'tla get' command, tla starts searching backwards for an
    > ancestor:

    > * ensuring library has address@hidden/a--b--c.d--patch-NNN
    > * searching ancestor revision in library in archive address@hidden

    > I assume tla is examining each patch's log in the remote archive to find
    > continuations, so it can check if an ancestor is already in my revlib.
    > The trouble is, this is extremely slow; nothing appears after the
    > "searching.." message for several minutes.  (I guess there's some
    > connection setup latency due to firewall and/or web-proxy issues.)

    > Is there any way of telling 'tla get' (or 'tla library-add' for that
    > matter) that I want it to go straight to the cacherev and use that, and
    > forget about trying to hardlink to an ancestor at all?  The checkout
    > would then be done in a second or two instead of many minutes.


The current heuristics have a strong bias towards the assumption that
your revlib is normally somewhat dense in the areas of history that
you are referring to.   Your first `get' after hundreds of revisions
of not `get'ing is therefore slow and a subsequent one, a smaller
number of revisions later, is much faster.

That said, yes, the heuristic is obviously letting you down in this
case and should be (and shall be) tweaked accordingly, possibly along
with a new library-config parameter.

-t