[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

[PATCH] Re: Issue #3354: copy operation during update fails

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 17 Jan 2009 03:40:57 +0000

On Tue, Jan 13, 2009 at 08:45:36PM +0000, Stefan Sperling wrote:
> I'm still hoping to get more eyes on trying to spot the real
> bug though.

Looks like the diff at the end of this mail fixes the problem

The output of my reproduction recipe with the patch applied is:

  + svn update recipe-issue-3354/trunk2
     C recipe-issue-3354/trunk2/alpha
  Conflict discovered in 'recipe-issue-3354/trunk2/alpha.moved'.
  Select: (p) postpone, (df) diff-full, (e) edit,
          (mc) mine-conflict, (tc) theirs-conflict,
          (s) show all options: p
  C recipe-issue-3354/trunk2/alpha.moved
  Updated to revision 3.
  Summary of conflicts:
    Text conflicts: 1
    Tree conflicts: 1
  + svn status recipe-issue-3354/trunk2
  ? recipe-issue-3354/trunk2/alpha.moved.copied
  ? recipe-issue-3354/trunk2/alpha.moved.r3
  ? recipe-issue-3354/trunk2/alpha.moved.mine
  A + C recipe-issue-3354/trunk2/alpha
> local edit, incoming delete upon update
  C recipe-issue-3354/trunk2/alpha.moved
  + cat recipe-issue-3354/trunk2/alpha
  alpha, modified
  + cat recipe-issue-3354/trunk2/alpha.moved
  <<<<<<< .mine
  alpha, modified
  alpha, modified after move
>>>>>>> .r3

I did not commit yet because I got test failures that happened during
make check, but which I could not reproduce by running the failing tests
individually. The test failures all had this error:
  ERROR: dump failed: subversion/libsvn_subr/io.c:2636: (apr_err=2)
Any ideas?

Can people please run make check with my diff and see if there are
any problems? Thanks.

Paul, I also tried running your test with this diff, without the XFail.
But I could not get the test to do anything useful. All it does is
complain about the root node of the working copy, and I don't understand
what's going on there:

  $ ./update_tests.py 52 2>&1
  Expected '__SVN_ROOT_NODE' and actual '__SVN_ROOT_NODE' in output tree are different!
   * Node name: __SVN_ROOT_NODE
      Path: __SVN_ROOT_NODE
      Contents: N/A (node is a directory)
      Properties: {}
      Attributes: {}
      Children: 1
   * Node name: __SVN_ROOT_NODE
      Path: __SVN_ROOT_NODE
      Contents: None
      Properties: {}
      Attributes: {}
      Children: None (node is probably a file)
  Unequal Types: one Node is a file, the other is a directory
  Output of commit is unexpected
    +-- svn-test-work
          +-- working_copies
                +-- update_tests-52
                      +-- A
                            +-- B
                                  +-- E
                                        +-- alpha.moved
  svntest.wc.State('svn-test-work/working_copies/update_tests-52/', {
  Traceback (most recent call last):
    File "/home/stsp/svn/svn-trunk/subversion/tests/cmdline/svntest/main.py", line 1310, in run
      rc = self.pred.run(**kw)
    File "/home/stsp/svn/svn-trunk/subversion/tests/cmdline/svntest/testcase.py", line 121, in run
      return self.func(sandbox)
    File "./update_tests.py", line 4205, in update_moves_and_modifies_an_edited_file
    File "/home/stsp/svn/svn-trunk/subversion/tests/cmdline/svntest/actions.py", line 1133, in run_and_verify_commit
      tree.compare_trees ("output", actual, output_tree)
    File "/home/stsp/svn/svn-trunk/subversion/tests/cmdline/svntest/tree.py", line 609, in compare_trees
      raise SVNTreeUnequal
  FAIL: update_tests.py 52: update moves and modifies a file with edits
Note that the expected status is as shown above in the output
of my reproduction script. Can you look into the test again
and see if you can make it fail without the diff and pass with
the diff? That would be great help! Thanks.


Fix issue #3354, update fails when file with local mods is
                 moved and modified

* subversion/libsvn_wc/merge.c
  (maybe_resolve_conflicts): Add copyfrom_text argument.
  (eval_conflict_func_result): As above, and also copy
   the copyfrom text into the working copy in case the user
   postpones conflict resolution.
  (merge_text_file): Track argument changes.

Index: subversion/libsvn_wc/merge.c
--- subversion/libsvn_wc/merge.c (revision 35299)
+++ subversion/libsvn_wc/merge.c (working copy)
@@ -445,6 +445,7 @@ eval_conflict_func_result(enum svn_wc_merge_outcom
                           const char *left,
                           const char *right,
                           const char *merge_target,
+ const char *copyfrom_text,
                           svn_wc_adm_access_t *adm_access,
                           const char *result_target,
                           const char *detranslated_target,
@@ -538,35 +539,18 @@ eval_conflict_func_result(enum svn_wc_merge_outcom
       case svn_wc_conflict_choose_postpone:
+ /* Issue #3354: We need to install the copyfrom_text,
+ * which now carries conflicts, into ACTUAL, by copying
+ * it to the merge target. */
+ if (copyfrom_text)
+ {
+ SVN_ERR(svn_wc__loggy_copy(log_accum, adm_access,
+ copyfrom_text, merge_target,
+ pool));
+ }
           /* Assume conflict remains. */
           return SVN_NO_ERROR;
- /* TODO: Issue #3354: And what if the conflicted file
- * does not yet exist on disk (i.e. in ACTUAL)?
- *
- * It looks like this code was written with the
- * implicit assumption that a copy of the conflicted
- * file already exists in ACTUAL.
- *
- * But that is not true in the 'copyfrom' case.
- * If a text conflict is found while merging local
- * changes from the copyfrom file to the copied file
- * added by the update, the merge_target only
- * exists in WC meta-data (because update_editor.c,
- * add_file_with_history(), put it there).
- * But it does not yet exist in ACTUAL!
- *
- * Since the merge_target is never created in ACTUAL,
- * the commands added to the log below fail miserably.
- *
- * So what we probably should be doing here is checking
- * whether the merge_target exists in ACTUAL, and if
- * it if does not, create it with conflict markers
- * intact, and in text-conflicted state.
- *
- * Well, that is my theory anyway.
- * I hope to be proven correct, but it's too late
- * at night already to test my theory... --stsp */
@@ -751,6 +735,7 @@ maybe_resolve_conflicts(svn_stringbuf_t **log_accu
                         const char *left,
                         const char *right,
                         const char *merge_target,
+ const char *copyfrom_text,
                         svn_wc_adm_access_t *adm_access,
                         const char *left_label,
                         const char *right_label,
@@ -809,6 +794,7 @@ maybe_resolve_conflicts(svn_stringbuf_t **log_accu
+ copyfrom_text,
@@ -917,6 +903,7 @@ merge_text_file(const char *left,
+ copyfrom_text,
Received on 2009-01-17 04:41:25 CET

This is an archived mail posted to the Subversion Dev mailing list.