Tom Lord wrote:
>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.
>
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:
>
> 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?
>
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).
> 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.
>
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 12 21:34:13 2003