Rereading this thread, I note three design issues, and one big
mistake:
1) (The big mistake) I said "node" where I should have said "node
revision". Oops.
2) I don't think I've seen any solution here to the "transitive merge"
problem, though perhaps I missed it.
3) The question of tree deltas was dismissed with:
Sander:
> For sake of simplicity I'm leaving the handling of tree deltas
> out of this proposal. This being resemblant to textual
> merging to a degree.
but I'm not convinced. I've mentioned some issues that come up in
that regard earlier, but here's another: Let's suppose that that
the changes on the merged-from branch rename a file. What does
this correspond to in the merged-to revision? In other words, how
does one identify which corresponding file is to be renamed? Note
that, in the merged-to revision, the renamed file may have a
different name and may have either a longer or shorter node id --
or even an unrelated node id. Worse, moreover, there may be
logically _different_ files in the merged-to revision that have the
same path, or a node id that is a "better match" than that of the
correct file for the node id in the changes. In other words,
neither node id or path is a good indicator for file identity for
the purpose of renames and other elements of tree deltas.
4) No consideration seems to have been given to auditing merges at the
project level.
-t
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 12 20:08:03 2003