Re: [Gnu-arch-users] back-building pfs updates

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > On Fri, Feb 20, 2004 at 01:10:54PM -0800, Tom Lord wrote:

    > > I'm generally against the idea of parallel operations, at least at
    > > this stage.   

    > I find this surprising, since we had a discussion recently in which you
    > said you'd like to make file-getting parallizeable.

Nothing stays the same quite so well as inconsistency :-)

    > Finding cachereves and continuation files currently requires at least 1
    > server round trip for every revision that may (but almost always
    > doesn't) contain a continuation file or cached revision.

    > But with http pipelining, I believe it could be reduced to two server
    > round-trips:
    > 1. List all revisions
    > 2. Get all revision directory listings

Well, hmmm.

That sounds desirable.  What I _don't_ want is (non-trivial) logic
above the archive.h layer that complicates the currently serial
archive abstraction.   

So, I wonder if that kind of pipelining can't be done at archive-pfs
or below --- with just a minimum of hints from the higher layers.

    > In my book, archive mirroring is too coarse a level of granularity.  I
    > don't want to download jblack's integration, though I do want his
    > contrib.  I don't want Robert Collin's barch stuff, just his
    > integration.  I don't want scheme, just tla--devo--1.2.

The "limit" facility of mirroring already gives you that.

I'd be in favor of higher level tools that help me to manage mirrors
-- set up (in a persistent way) what mirrors to update, when, and with
what limits.


    > But I don't want to make mirrors that aren't.  If I could mirror a
    > version without pretending to mirror an archive, I'd be willing to
    > consider it.

You can -- that's what the "[limit]" parameter in:

    update an archive mirror
    usage: tla push-mirror [options] [from [to] [limit]]

is for.

    > One of the major reasons I've looked at backwards building is because
    > when you have tla--devo--1.2--patch-50 in a revlib and you want patch-43,
    > it's frustrating to see tla walking backwards into tla--devo--1.1 to
    > find a cacherev, and  building from that.

    > My current backbuilding code assumes that continuations only happen at
    > base-0.  This is wrong, but for the trees I use, it's true.  It's much,
    > much faster, because it looks at the revision library to see what's
    > there, instead of iterating through each revision in the archive, and
    > checking to see if there's a revlib for it.

    > Continuations and cacherevs can happen anywhere, though.  And the actual
    > data isn't huge; it's the latency that kills us.  That's why I want a
    > two-round-trip approach, instead of an 0(n) approach where n is the
    > number of revisions.

That's fine.   I just don't want to hair up the code above archive.h
to achieve it.

-t