On Tue, Nov 06, 2012 at 03:03:32PM -0500, Mark Phippard wrote:
> Please see this thread from Subclipse mailing list:
>
> http://svn.haxx.se/subusers/archive-2012-11/0001.shtml
>
> Basically, a user has a recipe where an svn update has text conflicts.
> In addition to the usual conflict files, there is also a file named
> "foo.txt.edited" created. I can see in libsvn_wc/merge.c (in 1.7.x
> branch) that this can happen. In trunk this is now in conflicts.c.
>
> It is not clear to me what scenario triggers this, as I could not reproduce
> it.
>
It is created if the client sets 'save_merged' to TRUE in its
conflict prompt result:
/** If true, save a backup copy of merged_file (or the original
merged_file from the conflict description, if merged_file is
NULL) in the user's working copy. */
svn_boolean_t save_merged;
} svn_wc_conflict_result_t;
I guess supclipse somehow ends up setting this flag to TRUE.
The command line client currently sets this flag if the user chooses
'(e) edit' during interactive conflict resolution, and the user then
proceeds to pick any of these options:
- mine-conflict, theirs-conflict, mine-full, theirs-full
I suppose the file is saved just in case the user picks one of the
above options by accident?
> Anyway, it seems like the possible bug is that svn resolve does not
> remove this file as it does the others. Maybe if I could reproduce
> the problem I would understand why it is not removed, but it seems
> like a bug.
I can't find any code which removes the file.
The code on trunk doesn't use the save_merged result anymore with the
command line client. The command line client now always postpones conflicts
while an update or merge is in progress.
The new conflict resolving code, which was mainly written by Bert IIRC,
ignores the save_merged flag. I don't know if this is accidental.
The function svn_wc__conflict_invoke_resolver() which ends up looking
at save_merged exists only for backwards compat with clients that still
resolve conflicts while an update or merge is running.
