Re: [Gnu-arch-users] Re: [BUG] FEATURE PLANS: "perfect" summary deltas

[Aaron Bentley]

Tom Lord wrote:

> If a log entry (the latest (or such) in the summary-delta branch)
> becomes out-of-date because of deleted revisions, that means just one
> extra roundtrip (to discover a revision has been deleted).

If the log data is sometimes wrong, I think I have to always verify it,
with the latency issues that implies.   Whereas we can assume that the
directory listings aren't wrong, and don't need to be verified.  (If 
.listing files are wrong, that's an invalid archive)  So I think "delta 
directories" wins in that regard.

> Yes, clearly.  But your idea for generating deltas implies fairly
> significant and uncertain changes to the builder whereas mine implies,
> imo, fairly trivial and deterministic ones.

The changes you propose may be mathmatically simple, but I'm still 
trying to sort out how to convince the builder to *backwards* in order 
to go *forwards*.  The whole algorithm could probably be built in, but 
I'd rather build it out of smaller pieces, so it can use summary deltas 
even if some are missing.

> I have no problem making those special cases.   I wonder if something
> interesting can be done with them.

Perhaps they could be reserved for future "expansion" :-).  Seriously, 
removing those revisions would greatly reduce the space overhead for 
archive owners and those who mirror them.  Unless you can come up with 
something uber-cool to do with them, I'd much prefer to see them gone.

I don't believe there's a fundamental difference between submission
branch revisions and external deltas.  Naming conventions, of course,
will differ, but the changesets are the same, and the builder is 
supposed to use any SUBMITQ candidates that are suitable, without 
explicit user intervention.  Supporting either will require the same 
kinds of changes to the builder.  In your feature plan  for SUBMITQs, 
you propose to make to make the builder unpredictable:
"... := randomly_choose (SUBMITQ-CANDIDATES)",

Even if you have the direct ancestor in a revlib, you're still forced to 
use the SUBMITQ.  Even SUBMITQ-IDEAL is far from ideal in that case. 
Give me a way of determining file sizes and a directory of deltas, and I 
can build you a builder that will never make *that* mistake.

> I certainly don't want to implement submission branches that way
> (using your "delta" directory).  One way to understand the "point" of
> a submission branch is that I should be able to "get-patch" the
> changeset from it and it should represent a proposed divergence from
> some mainline.  

With external deltas, you could use 'tla delta' to get the same result, 
with the same changesets downloaded.  It would involve client-side 
changeset generation, but perhaps we can special-case that away.

> A purely "commit --continuation" branch fits the bill
> precisely --- all that's needed (at core) is to remove the restriction
> that currently prohibits "commit --continuation" revisions.

Maybe that's the only core issue, but there are a number of others:
- builder changes
- branch-naming changes
- name-mangling

Aaron