[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PROPOSAL] Merging Improved

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-04-12 21:33:25 CEST

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

This is an archived mail posted to the Subversion Dev mailing list.