History horizons spec

Aaron Bentley aaron.bentley at utoronto.ca
Mon Feb 27 12:50:08 GMT 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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?

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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEAvWA0F+nu1YWqI0RAoYUAJsHXfZUplhQm2MGt2djq4Y4usnbZQCgheOW
KSpS0/MIOVzhISG2/TnFs5Q=
=c2CC
-----END PGP SIGNATURE-----




More information about the bazaar mailing list