I am trying to puzzle out what per-file information needs to be kept in each branch. Modulo the differences in styles about directories, I think I'm trying to achieve the same things that the inversion project is trying to achieve. Mostly, I want to make sure that I haven't missed anything in the dependency graph construction. I'ld very much appreciate your thoughts if I have missed something.
Let's take a simple scenario first: Pardon my ascii art. The problem with fonted mail agents is that they don't render correctly except in Courier, and Outlook Express really wants to use Arial...
I assume that there is some "main" trunk, consisting of files A, B, and C. This main trunk is being modified in parallel with a branch. For this mail, I will use increasing numbers to indicate successive points in time *without* respect to which branch they were on. That is, the numbers capture the time sequence of events.
Imagine that there exists a trunk "main.1", from which we create a branch "branch.1". Initially, these consist of:
main.1
main.1:A
main.1:B
main.1:C
branch.2
main.1:A
main.1:B
main.1:C
That is, files are named according to the branch version in which they were most recently modified.
An edit is done on the main trunk, resulting in new versions of A and B. We now have:
main.3
main.3:A
main.3:B
main.1:C
An edit is now done on the branch, resulting in:
branch.4
The developer on the branch now wishes to merge the changes from main.2:B into their working branch. This results in:
branch.5
into branch.4:B)
So here is my question:
There are two ways I could record the series of changes to branch.5:B. One seems relatively complete, but perhaps is not needed. The other is simple, but may not meet all requirements.
The "complete" way is for each file in each branch to have a descriptive attribute that indicates whether the change to that file resulted from a merge. If so, we record the "base" of the merge (in this case: main.1:B) and the "top" of the merge (in this case: main.2:B). I am assuming that we will do one merge per file per commit in the branch. Strictly speaking, I could extend the merge attributes to cover sequences of merges, but it's more hassle than it is worth at the moment.
The alternative is simply to record a new "mergebase" for each file (in this case "main.2:B", where the previous merge base was "main.1:B"). This makes the assumption that every branch has exactly one parent (in this case: main), and that all merges into a branch will be from the parent into the branch.
In the simpler design, a branch re-integration proceeds as follows:
for each file
take delta = current - mergebase
apply delta to top of trunk
replace mergebase w/ new trunk top
commit both trunk and branch
So I suppose the question really comes down to: can we successfully enforce a lattice relationship on the branch hierarchy?
For the moment, I am going to proceed with using the completely attributed form for recording purposes, but restrict the changes to the simpler style.
I'ld really appreciate some insight on the algebra of change applications here
shap