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

[Bug Goo]

Created as bug 106

On Thu May  6 19:13:09 2004, Tom Lord wrote:
> 
>     > 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
> 
> 
> 
> _______________________________________________
> Gnu-arch-users mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnu-arch-users
> 
> GNU arch home page:
> http://savannah.gnu.org/projects/gnu-arch/
>