On Mon, Jun 13, 2016 at 4:10 PM, Stefan Sperling <stsp_at_apache.org> wrote:
> On Mon, Jun 13, 2016 at 01:51:49PM -0000, stsp_at_apache.org wrote:
>> Author: stsp
>> Date: Mon Jun 13 13:51:49 2016
>> New Revision: 1748236
>>
>> URL: http://svn.apache.org/viewvc?rev=1748236&view=rev
>> Log:
>> When merging an incoming file move, record this move in the working copy.
>>
>> This makes merged file moves appear as having been "replayed" on the local
>> branch, rather than as a delete and a copy from the merge source branch.
>> File content changes are preserved and may raise a text conflict if applicable.
>>
>> * subversion/libsvn_client/conflicts.c
>> (resolve_incoming_move_file_text_merge): If the conflict was flagged by a
>> merge operation, run a meta-data only move instead of just a deletion.
>>
>> * subversion/tests/libsvn_client/conflicts-test.c
>> (test_option_merge_incoming_move_file_text_merge): Update test expectations.
>>
>> Modified:
>> subversion/trunk/subversion/libsvn_client/conflicts.c
>> subversion/trunk/subversion/tests/libsvn_client/conflicts-test.c
>
> Just to raise awareness:
>
> As of this commit, interactive conflict resolution allows simple file
> moves to be merged between branches and boil down the text-conflicts.
> Example below.
Sweet! I've read through your example, and this looks really great!
I can't wait to start using it, and start promoting it to my user base
;-). Time to fire up a trunk build, and start looking at extending
those tests you mentioned.
BTW: until now it looks like the "m" option would usually be the
sanest option ("suggested option", as mentioned by swdev in the other
thread). At least, that's what I would recommend to my users, if they
don't want to think too hard: "just accept the (m)erge option, if
there is one" :-).
Great work!
--
Johan
Received on 2016-06-14 22:30:44 CEST