It (sometimes) saves the edited file, but nothing ever reads it afterwards. There's no way, for example, to install a partially edited conflicted file into the WC, then postpone the remaining resolution for later. :( On 21 Oct 2013 16:17, "Philip Martin" <phi...@codematters.co.uk> wrote:
> Philip Martin <philip.mar...@wandisco.com> writes: > > > Branko Čibej <br...@wandisco.com> writes: > > > >> On 18.10.2013 23:13, Branko Čibej wrote: > >>> Can someone explain what the purpose of the save_merged flag in the > >>> conflict result struct is? It's used once in our code, but as far as I > >>> can see, the resulting .edited file isn't actually by the code > anywhere. > >> > >> "Isn't actually *used by* the code anywhere" > > > > I'm not sure what effect it has but I see it set by the client in: > > > > subversion/svn/conflict-callbacks.c:handle_text_conflict > > > > and used by the library in: > > > > subversion/libsvn_wc/conflicts.c:resolve_text_conflict > > The log message is: > > r871101 | glasser | 2008-05-05 16:22:04 +0100 (Mon, 05 May 2008) | 28 > lines > > At the conflict resolution prompt, if the user plays with the merged > file (by choosing (e)dit or (l)aunch) and then chooses one of the > resolution options that ignores the merged file ([mt][cf]), save a > copy of the merged file as "foo.edited". > > This does not affect --accept. > > So it's saving a copy of a file that the user has edited? > > -- > Philip >
