On Wed, Jun 12, 2013 at 5:46 PM, Stefan Sperling <s...@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 <s...@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
