Re: 1.6 blocker? copy operation during update fails

Hi guys,

I've been looking at this, but in the end am back to square one. Anyway,
I've established that r34158 entirely changes the code path for this
scenario (issue #3354), and that's ok. :P

So we probably just look for some indicator to prevent that offending loggy
entry Julian pointed out, for this particular case. That's how far I got
today. Will probably go on tomorrow.

I doubt that it helps, but below is what I traced around in.

~Neels

The error happens since r34158,
which changes subversion/libsvn_wc/update_editor.c.

The update calls merge_file() in update_editor.c.

When I compare the traces of r34158 with r34157, they separate at this
point:

(line numbers in current trunk)
subversion/libsvn_wc/update_editor.c:3715
[[[
  if (fb->copied_working_text)
    is_locally_modified = TRUE;
  else if (! fb->existed)
    SVN_ERR(svn_wc__text_modified_internal_p(&is_locally_modified, fb->path,
                                             FALSE, adm_access, FALSE, pool));
  else...
]]]

r34158 takes the first case: is_locally_modified = TRUE.
r34157 takes the second case and determines is_locally_modified = FALSE.

This is because of fb->copied_working_text differing between the traces.
On r34158 it is "3354/trunk2/.svn/tmp/tempfile.2.tmp" and
on r34157 it is 0x0.

It has this doc
[[[
  /* If this file was added with history, and the copyfrom had local
     mods, this is the path to a copy of the user's version with local
     mods (in the temporary area). */
  const char *copied_working_text;
]]]
and it sounds like it makes sense. It even sounds like it is addressing the
copyfrom side, like trunk successfully relates the locally modified file
alpha with the incoming alpha.moved.

In effect,
r34158 goes into the /* working file or obstruction is locally modified...
*/ if clause and goes into a merge situation. Wow.
r34157 goes into the (! is_locally_modified && ! is_replaced) clause and
apparently does something by far simpler.

So, let's find where this fb->copied_working_text is coming from all of a
sudden. It does not appear in the diff -c34158.

It comes from update_editor.c:3000, add_file_with_history():
[[[
     if (text_changed)
        {
          /* Make a unique file name for the copied_working_text. */
          SVN_ERR(svn_wc_create_tmp_file2(NULL, &tfb->copied_working_text,
                                          svn_wc_adm_access_path(adm_access),
                                          svn_io_file_del_none,
                                          pool));

          SVN_ERR(svn_io_copy_file(src_path, tfb->copied_working_text, TRUE,
                                   subpool));
        }
]]]
, where src_path is actually pointing at "alpha" while handling
add_file_with_history(path="alpha.moved").

I'm starting to think all this is intended. So I guess we rather mend the
situation instead of bothering with the cause.

Duh. Back to square one.

Julian Foad wrote:
> Paul or Neels,
>
> Please could one or both of you look into this. Stefan and I don't have
> the spare cycles at the moment.
>
> Thank you.
> - Julian
>
>
> On Wed, 2009-01-07 at 13:28 +0000, Julian Foad wrote:
>> Julian Foad wrote:
>>> I'll be looking at this, of course. It looks like a tree-conflict bug.
>> Debugging...
>> subversion/libsvn_wc/merge.c:648 in svn_wc__merge_internal():
>>
>> [[[
>> /* Back up MERGE_TARGET through detranslation/retranslation:
>> the new translation properties may not match the current ones */
>> SVN_ERR(svn_wc_translated_file2(&tmp_target_copy,
>> merge_target,
>> merge_target,
>> adm_access,
>> SVN_WC_TRANSLATE_TO_NF
>> | SVN_WC_TRANSLATE_NO_OUTPUT_CLEANUP,
>> pool));
>> SVN_ERR(svn_wc__loggy_translated_file
>> (log_accum, adm_access,
>> target_copy, tmp_target_copy, merge_target, pool));
>> ]]]
>>
>> Somewhere about here, the code writes a log instruction to
>> copy-and-translate the file "alpha.moved" which does not exist.
>>
>> Just before executing this code,
>> merge_target = "recipe-i3354/trunk2/alpha.moved"
>>
>>
>> Tracking down the introduction of the bug by a binary chop...
>> it's r34158:
>> "Fix update/switch to skip all tree conflict victims and their
>> descendants. Skip both newly-discovered and existing tree conflicts."
>>
>> This change doesn't touch that file "merge.c".
>>
>> That's where I've got to so far.
>>
>> - Julian
>>
>> ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1009930
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1013029