Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta

subversion
Discussion topic

Back to topic list

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

Author neels
Full name Neels Janosch Hofmeyr
Date 2009-07-21 06:36:04 PDT
Message 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
Attachments

« Previous message in topic | 8 of 22 | Next message in topic »

Messages

Show all messages in topic

Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-10 03:35:24 PDT
     Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-11 15:34:49 PDT
         Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-11 17:04:55 PDT
             Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-18 14:20:07 PDT
                 Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-19 10:53:47 PDT
                     Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-20 19:31:53 PDT
                         Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta stsp Stefan Sperling 2009-07-21 04:44:44 PDT
                             operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-21 06:36:04 PDT
                                 Re: operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta stsp Stefan Sperling 2009-07-21 07:44:55 PDT
                                     Re: operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta gavinbaumanis Gavin Baumanis 2009-07-21 16:33:05 PDT
                         Defining atomic "replace" [was: svn commit: r38394 - in trunk/subversion: include libsvn_delta] julianfoad Julian Foad 2009-07-28 03:28:37 PDT
                             Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-11 11:53:36 PDT
                                 Re: Defining atomic "replace" gstein Greg Stein 2009-08-11 13:04:12 PDT
                                     Re: Defining atomic "replace" Bill Tutt <bill dot tutt at gmail dot com> Bill Tutt <bill dot tutt at gmail dot com> 2009-08-13 07:41:32 PDT
                                         Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-13 16:24:48 PDT
                                             Re: Defining atomic "replace" Bill Tutt <bill dot tutt at gmail dot com> Bill Tutt <bill dot tutt at gmail dot com> 2009-08-14 11:12:04 PDT
                                 Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-11 16:27:08 PDT
                                     Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-11 16:31:17 PDT
                                     Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 10:51:43 PDT
                                     no-op-copy -- was: Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 12:00:55 PDT
                                         Re: no-op-copy -- was: Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-12 17:03:11 PDT
                                             Re: no-op-copy -- was: Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 17:53:07 PDT
Messages per page: