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

[Stefan Sperling <st...@elego.de>]

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 <st...@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

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

[Julian Foad <ju...@btopenworld.com>]

Issue #1425 summary is "make 'svn merge' less fragile", and initial description is:
[[[
We have a general problem that 'svn merge' dies too easily.  This
command should behave much like 'patch' -- that is, if a hunk of tree
delta fails to apply, just warn the user, and move on.
]]]

That was in 2003. Clearly we have moved on and now expect "merge" to be more 
robust and ensure all requested changes have been either merged in or flagged 
as conflicts.

Stefan Sperling wrote:
> 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:
[...]
>   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"?

Yes, please do.

- Julian

> 
> 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?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org