Re: multiple tree-conflicts during merge -- was: Re: Error reading spooled REPORT request response

Fix committed in r38000 and r38006.

Thanks, Wilfredo Sánchez Vega, for the report!
~Neels

Neels Janosch Hofmeyr wrote:
> Neels Janosch Hofmeyr wrote:
>> Wilfredo Sánchez Vega wrote:
>>> I'm running into this error while trying to do a merge:
>>>
>>> --- Merging r4130 through r4318 into '.':
>>> U lib-patches/Twisted/twisted.python.util.patch
>>> svn: Attempt to add tree conflict that already exists
>>> svn: Error reading spooled REPORT request response
>> Hmm, looks like a solid bug. Investigating...
>
> BTW, I successfully reproduced this issue.
> In case you're interested, it's because a deletion and addition happen in
> one merge range, onto a file that was also modified in the target branch. To
> work around it, you could merge selected ranges and resolve tree-conflicts
> after each range.
>
> But to find out which files and ranges are involved is not that simple. I've
> also been thinking about that one and might come up with a little tool soon.
>
> Anyway. I'm still struggling to find the proper fix for this issue, in *theory*.
>
> How to handle multiple tree-conflicts within a given merge range? i.e. in
> a given range, file alpha was removed, later added, later removed again. I'm
> merging that onto another branch that has modified file alpha. For further
> argument, make the "later added" an "added-with-history", so that it is
> again the "exact same" file with history and all.
>
> What do I want to see -- The first delete? The last delete? Only the "arch"
> over all consecutive delete/add/delete/add operations? (As in, if the last
> one was an add, process an edit, if the last one was a delete, process a
> delete?)
>
> What should `svn info' show -- the merge range given on the command line?
> The revision number that tried to delete the file (whih one)?
>
> I'm still pretty uncertain about that stuff.
>
>
> My reproduction script is attached.
> In the script, also note that passing the file in question as an explicit
> target (instead of recursing on the parent dir) totally fails to see a
> tree-conflict in the first place. It's as if the merge lost its voice.
>
> If I don't come up with an idea soon, I'll make this a new issue.
>
> ~Neels
>
>
>> Thanks for the report! So you got my message on IRC ;)
>> I'll be back later, hopefully with a fix.
>>
>> ~Neels
>>
>>> The client and server are both running svn version 1.6.2.
>>>
>>> This merge completes without errors if I use svn 1.4.4 client (had
>>> that on another machine; didn't try anything in between), which
>>> suggests that this is a regression.
>>>
>>> The script below will reproduce this on my system.
>>>
>>> -wsv
>>>
>>>
>>> #!/usr/bin/env bash
>>>
>>> # Create a temporary directory
>>> tmp="$(mktemp -d -t foo)";
>>> cd "${tmp}";
>>>
>>> # Check out CalendarServer
>>> svn co -r4315 http://svn.calendarserver.org/repository/calendarserver/CalendarServer/trunk
>>> CalendarServer;
>>> cd CalendarServer;
>>>
>>> # Merge all changes on the update-twisted-3816-3 since it's creation
>>> (r4129)
>>> svn merge -r4129:HEAD http://svn.calendarserver.org/repository/calendarserver/CalendarServer/branches/exarkun/update-twisted-3816-3
>>> ;
>>>
>>> # Print the WC path
>>> echo "WC is: $(pwd)";
>>>
>>> ------------------------------------------------------
>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359252
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359433
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359772
>

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