tree conflicts conflict with part of the fix for issue #1425

Hi,

I'm in the process of going over failing tests on the tree-conflicts
branch and trying to fix them.

This one is causing trouble:

# Issue #1425: 'svn merge' should skip over any unversioned obstruction

def merge_skips_obstructions(sbox):
  "merge should skip over unversioned obstructions"

It causes a tree conflict and currently fails with:

  =============================================================
  Expected '__SVN_ROOT_NODE' and actual '__SVN_ROOT_NODE' in output tree are different!
  =============================================================
  EXPECTED NODE TO BE:
  =============================================================
   * Node name: __SVN_ROOT_NODE
      Path: __SVN_ROOT_NODE
      Contents: None
      Properties: {}
      Attributes: {}
      Children: N/A (node is a file)
  =============================================================
  ACTUAL NODE FOUND:
  =============================================================
   * Node name: __SVN_ROOT_NODE
      Path: __SVN_ROOT_NODE
      Contents: N/A (node is a directory)
      Properties: {}
      Attributes: {}
      Children: 1
  Unequal Types: one Node is a file, the other is a directory

In the related issue, Ben Collins-Sussman said:

  * deal with unversioned obstructions: what if merge wants to
    add/delete/change something that is unversioned? Just keep going,
    print 'skipped unversioned target', rather than bombing out as it
    currently does.

Quote from the "USE CASE 4" section in notes/tree-conflicts/detection.txt:

  If 'svn merge' tries to modify a file that does not exist in the
  target working copy, then the target file is a tree conflict victim.

So by this logic, the file obstructing the add in the merge is
becoming a tree conflict victim.

Is it OK if we change the behaviour introduced by the fix for
issue #1425 accordingly, i.e. flagging a tree conflict instead
of printing "skipped unversioned target"?

Or should we make Subversion treat unversioned items specifically
not as tree conflict victims for some reason?

In the former case, the test could be renamed to "unversioned obstructions
during merge should cause tree conflicts" and be adjusted accordingly.

Ben, what is your opinion?

-- 
Stefan Sperling <stsp_at_elego.de>                 Software Developer
elego Software Solutions GmbH                            HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12        Tel:  +49 30 23 45 86 96 
13355 Berlin                              Fax:  +49 30 23 45 86 95
http://www.elego.de                 Geschaeftsfuehrer: Olaf Wagner