History horizons spec

[John Arbash Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
> | Ultimately, I think it will be nice to have some sort of
> | check-pointing/history horizon system, so that new branches don't have
> | to contain all of history.
> |
> | I think it would make more sense to do it as a remote reference, though.
> | So you could say, "this is the history I have, for older ancestors, look
> | here..."
> 
> We already have 'this is the history I have', by implication.  I agree
> that we could provide a way for repositories to fall back to other
> repositories, but I see this as complementary to history horizons, not
> an alternative.
> 
> | I think we could still keep the ancestry graph for them, just to make
> | things easier.  I would like to see us keep a revision_id, parent_ids,
> | and testament sha1. That way we can historical integrity, as
> | well as selecting merge bases, etc.
> 
> I don't know about 'historical integrity'.  What would it allow us to do?

Make sure that if we ever request an old revision, it actually matches
what we said it was. It bothers me a lot right now that we don't
actually verify most of the sha1 hashes. I put in the code to verify the
Weave.get_lines() so we at least check that the text matches what the
weave says it should. But we don't check that the inventory sha1 matches
the Weave's sha1, and we certainly don't check that Revision points to a
valid inventory. (The sha1 we have right now is *probably* correct, but
it wouldn't handle any sort of upgrades, etc).

I would really like to be able to say both that this revision id is my
ancestor, and that it should have a hash of this. We got rid of the
chained hashes, because they didn't work properly with ghosts, and they
made upgrading difficult.

I would like to track the ancestors + their hash. I don't think it would
add a lot of overhead (its not like the Arch patch log problem).

> 
> As I described in the spec, using such data to select a merge base looks
> like optimizing a corner case.  And not very well, either, because you
> still have to download the merge base from the repository.  Though I
> guess it's better than downloading the entire repository so you can
> select a merge base, when the merge base turns out to be recent.
> 
> | And by having the 'remote reference', if you don't have all the data
> | here, you have an idea where you can go fetch it to finished doing your
> | work.
> 
> I don't understand this sentence.
> 
> Aaron

(just the idea of having a fallback location, so that you can get
information you might be missing).

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060227/9aed618d/attachment.pgp