Re: [Monotone-devel] Keyword substitution?

[Todd A. Jacobs]

On Tue, Aug 02, 2005 at 12:21:28PM -0500, Timothy Brownawell wrote:

> Hmm? If a db has a given revision, it must also have all ancestors of
> that revision. And part of what defines a revision is which other
> revisions it is descended from, so that ancestor set is always the same
> for a given revision. History cannot differ between repositories.

Why not? Just because a given revision needs to have common ancestors 
doesn't mean that *all* ancestors are present in the revision history. 
Take three theoretical repositories R1, R2, and R3:

R1-A    R2-A    R3-A
 |       |       |
R1-B<-----+   |
 |        |      |
R1-C    R2-C     |
 |        |      |
 +<----R2-D---->+
 |        |      |
R1-E    R2-E    R3-E

Pardon the poor diagramming, and the oversimplification, but it seems to 
me that R3 won't contain the entire revision history stored in the other 
repositories--just enough patch sets to create a common ancestor for 
head revisions. Given a few additional generations and a few more 
repository peers, and I think the problem would only be exacerbated.

This example might not contain enough commutations and patch sets to 
really bear out what I'm thinking, but the point I'm trying to make is 
that, *as I understand it*, you can't be assured that the hash of a file 
will match any of the revision numbers in your repository--and given the 
nature of hashes, you can't reconstruct a revision that way.

So, being able to identify a file as revision X from repository Y would 
seem to be necessary in such an instance. --Or am I missing something 
fundamental to the design?

--
Re-Interpreting Historic Miracles with SED #141: %s/water/wine/g