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

[Aaron Bentley]

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.

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

> It counts as premature optimization at complexity cost
> in my book.   It's foolish for local operations and I'd rather see
> emphasis on making sure that local operations are the common case.

> In other words, in my current thinking, a little 3-line convenience
> feature hack for archive-mirror is worth a 300 line revision for
> parallel operations.    A less latency-bound archive-mirror at a cost
> of 1500 lines is worth 150,000 lines of parallel operation code.

Archive-mirror isn't interesting to me, except for publishing my own
mirror.

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.

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.

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.

Aaron