Tom Lord wrote:
>Rereading this thread, I note three design issues, and one big
>1) (The big mistake) I said "node" where I should have said "node
> revision". Oops.
That happens to the best of us. :-)
>2) I don't think I've seen any solution here to the "transitive merge"
> problem, though perhaps I missed it.
If I understand correcly what you mean by transitive merge, then
recording the branch points on the way to the MRCA is exactly what we
need to solve the problem, isn't it?
>3) The question of tree deltas was dismissed with:
> > 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?
That's what the node ID is for. It uniquely identifies a versoined
object in the repository (or at least, it will once the atomic rename
fix is in).
> 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.
Nope, node IDs are just unique integers, and they're supposed to be
unique for an object on all branches. Maybe you're thinking of the old,
CVS-like way we used to generate node IDs; thankfully, we got rid of
that along the way.
> 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.
The path is indeed not enough to identify either node or branch; but the
node id identifies the node, and the copy id identifies the branch;
conversions between path+revision and node-id+copy-id are trivial,
although they do involve queries to the server.
>4) No consideration seems to have been given to auditing merges at the
> project level.
Do you mean reviewing the results of a merge before they're committed,
or something else?
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Apr 12 21:34:13 2003