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

operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta

From: Neels Janosch Hofmeyr <neels_at_elego.de>
Date: Tue, 21 Jul 2009 15:34:36 +0200

Stefan Sperling wrote:
> On Tue, Jul 21, 2009 at 04:30:53AM +0200, Neels Janosch Hofmeyr wrote:
>> - is it ok to disallow multiple add() and delete() calls on the same path,
>> in principle?
>> e.g. during merge, there are only the two sides, merge-left
>> and merge-right. A replace means that both exist but are "unrelated". So
>> a merge will never need to send more than one (delete, add) tuple.
>> Usually it's either *one* delete or *one* add. The (add, delete) tuple
>> simply cancels out, nothing being sent.
>>
>> But are there cases where we also send all the steps in-between? Then we
>> could allow this: add(), add(REPLACES_REV), add(REPLACES_REV), delete().
>> But *are there*?
>>
>> - is it necessary to disallow multiple add() and delete() calls on the same
>> path, to make the atomic replace useful?
>> e.g. during merge, the receiver needs to cache all delete()s and match
>> with add()s, carrying out the leftovers during dir_close(). And merge
>> is not the only one in need of this quirky code construct.
>> I want to eradicate this madness -- I'd love to force atomic replaces
>> on everyone, so the receivers are entirely relieved of this quirkiness.
>> Will allowing both separate and atomic replace calls defy my plan by
>> actually adding more code to the receivers?
>>
>> - is there a case where separate calls have a different meaning than an
>> atomic replace?
>> e.g. for merge, it doesn't matter whether the nodes are "related".
>> I can't think of any case where we'd want to highlight that the node was
>> deleted and later re-added with the same history, or something. Right?
>>
>> ~Neels
>
> Note that if we ever switch to operation-based merging, a sender
> might send mulitple replace calls for the same item.
>
> Right now, Subversion just looks at the static difference between
> the source and target branches, and tries to eliminate this difference.
> Operation-based merging adds a notion of time to this difference.
> It means that tree operations such as copy, delete, add, replace
> would be replayed in order on the target branch just like they
> happened on the source branch in the revision range being merged.
>
> This would make handling tree conflicts much easier, and would also
> deal with other wrinkles, such as the fact that copies aren't being
> merged from one branch to another in a useful way.[*]
>
> The editor interface should allow for this kind of operation.
> In the long term, I hope to see Subversion do operation-based merging.

That's quite an interesting perspective.
Thanks!

>
> Stefan
>
> [*] We end up merging "svn copy /branch/A /branch/B" from branch
> to trunk as "svn copy /branch/B /trunk/B" while it should be
> "svn copy /trunk/A /trunk/B" plus merging any additional textual edits
> made in /branch/B since its inception into /trunk/B.
> Right now, edits made to /trunk/A after branching do not make their
> way into /trunk/B in the merge result, which is wrong since B is
> supposed to be a copy of A on trunk, too, but ends up not being a copy
> of /trunk/A. And it's even worse with moves because changes made to A
> after branching just get dropped in <1.6. In 1.6 and beyond, we're
> flagging a tree conflict on A, (local edit, incoming delete upon merge)
> but we should be handling this automatically. And IIRC detecting this
> case doesn't even work for directories right now.

whoa, stsp, you sometimes have a way of writing a really complicated example
in one huge paragraph rant. I admittedly do not understand every detail in
this one... but I do have a question:

A /trunk/A
    |
    |\_________svn copy ^/trunk ^/branch___________
    | \
M /trunk/A (1) |
    | svn copy A B
    | A+ /branch/B
    | |
    | M /branch/B (2)
    | |
    | <--- merge ---{ |
A+ /trunk/B (3) |

So you argue that (3) should contain *both* the edits (1) and (2), instead
of just (2)? It seems to me that it is impossible to know whether a user
wants that or not!

I can imagine both cases:
 - "What!? Why did it not merge the edits on /trunk/A (1)?"
 - "What!? It included all the edits on /trunk/A (1) as well?"

I would probably have been asking the latter, *not* expecting trunk/B to
contain (1). So operation based merges would throw me off at first.

If I got it right and you're sure about it, it seems to me like this
situation needs some kind of conflict resolu
 * neels stops short.

I'll rather keep quiet before we add another column for "merge conflicts"
;)

~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372974

Received on 2009-07-21 15:36:19 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.