On Wed, Jun 12, 2013 at 5:46 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jun 12, 2013 at 05:24:39PM +0200, Johan Corveleyn wrote:
>> On Wed, Jun 12, 2013 at 3:44 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> > On Wed, Jun 12, 2013 at 03:27:58PM +0200, Johan Corveleyn wrote:
>> >> I'd say, just edit the moved file with the incoming content, embedded
>> >> in conflict markers, just like what we do for text conflicts. That, I
>> >> think, would be as good as possible.
>> >
>> > That's basically what updating the move is doing anyway.
>> > I wouldn't want to apply the incoming changes to the moved file
>> > without also clearing the conflict marker.
>>
>> But that's what we do with text conflicts if you postpone them. We
>> modify the working file (with conflict markers), and leave the
>> conflict in place.
>
> No. The conflict markers are already there when the resolver runs!
> They are the result of a diff3 merge performed during the update.
For reference, Stefan and I continued this discussion on IRC:
http://colabti.org/irclogger/irclogger_log/svn-dev?date=2013-06-12#l183
In the end it dawned on me that the big difference with text
conflicts, is that we don't have / store the complete representations
of both sides of the conflict in the working copy (e.g. tree.mine,
tree.rN, ... like file.txt.mine, file.txt.rN, ...). That makes it near
impossible to implement a general "postpone" that keeps around
everything for you to look at (and still have the ability to rerun the
resolver to choose other options).
Perhaps there could be a special solution for the simple case under
discussion (single file move with an incoming edit on that file), but
certainly not a general solution for tree conflicts.
BTW, Stefan, I really like the 1.8 improvement, it's already a big
step forward (so this is not intended as criticism... just thinking
out loud trying to make sense of it all, and looking further ahead).
--
Johan
Received on 2013-06-13 00:25:18 CEST