> When we are tracing a change back thru the system, do we want to know the
> branch where it was first entered, or the place where two branches were
> merged to make the current ancestor.
It's not an either-or situation, since you can recover the transitive predecessor graph. The question is whether to record the merge point or not. Alternatively, the question is whether the merge logically should be viewed as producing a new entity.
The following may or may not help (excuse ascii art, please). When we look at the *branches* we tend to think about a picture that looks like:
B.1----B.2
/ \
but when you look at some particular entity, you might find that no changes occurred on the A path or the B path. The question is whether you want the graph for the entity to map directly to the graph you were imagining for the branch behavior in this case.
> Is there any use for this feature beyond code archeology? If there isn't,
> then the needs of the (human) code archeologist become key for deciding
how
> to handle the situation.
I think there is, because of the way the merge algorithm works. Merge operates by identifying entity triples of the form (workspace version, ancestor, version to merge). The ancestor is determined by computing the nearest common ancestor of the merge version and the workspace version. Generally, the nearer the ancestor the happier things will be.
By introducing a "contentless join" at the point marked <join> in the diagram, you effectively establish a lower bound on how far back subsequent merges will need to look to find a common ancestor.
There would seem to be two advantages to the contentless join: (1) nearer ancestors are generally better, and (2) they set a floor that is common *across* the entity-wise joins. That is, unless there has been later selective merge/join behavior, a merge/join after the point marked <join> in the diagram will reach the same ancestor for all entities to be merged.