You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2012/11/06 21:03:32 UTC

When does update/merge conflict produce .edited file?

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.

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.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: When does update/merge conflict produce .edited file?

Posted by Stefan Sperling <st...@elego.de>.
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.

Re: When does update/merge conflict produce .edited file?

Posted by Mark Phippard <ma...@gmail.com>.
Think this turns out to be a bug with SVNKit only.  It appears to
create this file even when postponing conflict resolution.  Sorry for
the noise.



On Tue, Nov 6, 2012 at 3:17 PM, Mark Phippard <ma...@gmail.com> wrote:
> It seems like this is the relevant commit:
>
> http://svn.apache.org/viewvc?view=revision&revision=871101
>
> Not sure how the behavior may have been amended since that commit as
> it is kind of old.  But the log message would explain why I did not
> see it when I tried to do this as I did not take the (E)dit option.  I
> have gone back to the user to verify their recipe is correct.
>
> Mark
>
>
>
> On Tue, Nov 6, 2012 at 3:03 PM, Mark Phippard <ma...@gmail.com> 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.
>>
>> 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.
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>
>
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

Re: When does update/merge conflict produce .edited file?

Posted by Mark Phippard <ma...@gmail.com>.
It seems like this is the relevant commit:

http://svn.apache.org/viewvc?view=revision&revision=871101

Not sure how the behavior may have been amended since that commit as
it is kind of old.  But the log message would explain why I did not
see it when I tried to do this as I did not take the (E)dit option.  I
have gone back to the user to verify their recipe is correct.

Mark



On Tue, Nov 6, 2012 at 3:03 PM, Mark Phippard <ma...@gmail.com> 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.
>
> 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.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/



-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/