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.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2373778
Received on 2009-07-22 01:33:35 CEST