Login | Register
My pages Projects Community openCollabNet

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

subversion
Discussion topic

Back to topic list

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

Author gavinbaumanis
Full name Gavin Baumanis
Date 2009-07-21 16:33:05 PDT
Message On 22/07/2009, at 00:44 , Stefan Sperling wrote:

> On Tue, Jul 21, 2009 at 03:34:36PM +0200, Neels Janosch Hofmeyr wrote:
>>> [*] 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.
>
> Your diagram sums it up nicely though :)
>
>> 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!
>
> True, there is ambiguity. There is more than one way to merge this.
>
>> 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?"
>
> Does it need to be configurable? I'd imagine that merging the
> edits by default is a safe thing to do. Note that e.g. Mercurial
> does this by default, so there is precedence.
>
>> 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.
>
> In a huge merge, it's easier to revert a textual edit you don't want,
> and which you can see in svn diff, than to find an edit which should
> have happened but didn't. And which you can't tell from svn diff so
> it's easy to overlook -- you may see it as part of a file being
> deleted
> but if it's a huge file who is going to bother checking every line
> for things they want to keep in the copy?
>
>> 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.
>
> We could flag a tree conflict and have the edits be applied
> to the victim by default. Just like we currently schedule some
> victims A+ by default to make it easy for people who want to keep
> the victim. People who do not want to keep the A+ victim can just run
> 'svn revert victim' to unschedule it. People who do not want the
> edits in the copy can just revert them. At least the edits have
> been brought to their attention this way. And that's what Subversion
> is supposed to do -- helping people with keeping track of changes.
>

+1

Not knowing that something didn't happen is a lot harder to diagnose -
especially if it is out of sight.

And since I am not a developer I am loathed to add comments that
require extra work.... but if it could be flagged as being abnormal,
via some sort of conflict property, then that would also assist the
end-user with making an informed decision about the resultant operation.

Gavin.
Attachments

« Previous message in topic | 10 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: