Re: [Monotone-devel] Keyword substitution?

[Justin Patrin]

On 8/2/05, Todd A. Jacobs <address@hidden> wrote:
> 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.
> 

I think you're fundamentally misunderstanding what monotone does here.
Monotone doesn't deal in "patch sets". You don't ship single patch
sets around, you sync your *entire* DB with another. So if you get one
of the revisions you also have its history. This could break down in
one of 2 scenarios I can think of, though.

1) You take the file from one monotone DB and manually import it into
another. (Rather than syncing with another machine). I don't see this
as viable.

2) You have different branches in each DB and are propagating between
them while not syncing all branches to all servers. In this case it
may be possible (I haven't tested this) to have a propagate from one
branch show up in one DB while not having the revision history.
However you would still have the pointer to the other revision and it
would still exist in the other DB. To do this both of the branches I'm
talking about would have to be on one server anyway in order for the
propagate to happen, so it would only be one specific copy which may
not have the ancestors from the other merge. But it would still be
part of its revision history...you'd just have a broken tree.

-- 
Justin Patrin