Nope. I still wasn't clear.
> Okay, I think I get you now.
>
> I think that the answer is, you don't need to explicitly store a reference
> to the common ancestor, since it's trivial to walk the tree from any two
> related entities and find out what the common ancestor was.
That wasn't the question. The question is whether you need to store a reference from the entity back to its containing branch. Entities already name their immediate predecessors, and you can definitely find the nearest common ancestor without knowing the containing branch, and the merge can proceed on that basis.
The problem is that you don't know what branch and version the common ancestor was part of. As a result, there is no way to describe to the user which entities were party to the three way merge. Originally, I ommitted this back pointer because an entity can be part of many branch versions in an equally first class way, so it wasn't clear what the back pointer should point to.
> Also, I'm not sure it's at all important to know the common ancestor of
> corresponding entities on different branches.
Yes, it is. Without this you can't do merge correctly. Check Josh's paper.
> In TeamNet, I could trivially freeze a version at
> any time, and all subsequent editing of my work area would then take place
> in the new "open" checkpoint.
I think we can get close to that. It wil require copying files into the local repository, but that's decently fast and the SHA's make the candidates pretty easy to find. TeamOne actually did this copy; it just did it lazily.
shap