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