#3334: schedule a WC item for re-add when tree-conflicted - help please!

Hi WC experts, tree conflict folks, and others.

I'm trying to solve issue #3334 as explained below,
in /branches/issue-3334-dirs/. (Patch attached of the current state of
the branch.)

I've been trying the "modify the WC entries" approach. It's hard because
I don't know exactly how ot modify the entries to achieve the desired
end, but it's close. It's mostly working, but there's an error (huh, of
course).

Can anyone see what I've missed that causes the error during commit that
you can see at the end of this message?

And any amount of reviewing of this patch is greatly appreciated...

Synopsis
========

Let's say D1 is a directory under version control, at r3, with local
mods (maybe in its children). We update D1 to r4, in which it has been
deleted in the repository. The update raises a tree conflict:

  $ svn up
  ___C D1

Now, we want this update to schedule D1 to be re-added as a copy of
D1_at_3, so that it is ready for the user to choose "resolve --accept=mine"
to keep it.

Definition
==========

D1 should end up exactly the same in these two scenarios:

New scenario:
[[[
  svn checkout -r3 # in which D1 exists
  modify_d1 # make local mods in D1
  svn update -r4 # tries to delete D1
  svn resolve --accept=mine # keep the local, re-added version
]]]

Existing scenario:
[[[
  svn checkout -r4 # in which D1 does not exist
  svn copy -r3 D1 . # make a pristine copy of D1_at_3
  modify_d1 # make local mods in D1
]]]

where modify_d1 makes property changes to D1 itself and/or
adds/deletes/modifies any of D1's children.

  
Code Paths
==========

In the update editor, the sequence of edits contains:

  - Blah(sibling of D1)...

  - Delete_entry(path='D/D1', parent='D')

  - Blah(sibling of D1)...

In do_entry_deletion(D1) called from delete_entry():

  - Detect the tree conflict

  - Normal code path:
      # Delete the place-holder entry 'D1' from parent adm dir, and
      # delete the whole tree 'D1' from disk
      svn_wc__loggy_delete_entry()

    Tree Conflict code path:
      # Schedule for re-add (recursively)
      schedule_existing_item_for_re_add(D1)

  - Write and run the logs, and return.

See schedule_existing_item_for_re_add() in the attached patch.

Testing
=======

Using update_tests.py 48, I make the test stop before the "svn update",
and run that by hand:

Then I check the status and resolve as "mine", i.e. the version we've so
carefully constructed:
[[[
$ cd obj-dir/subversion/tests/cmdline/svn-test-work/working_copies/update_tests-48/

$ cd local_leaf_edit_incoming_tree_del/

$ svn st -vu D)
A + - ? ? D/D1/delta
A + C - 2 jrandom D/D1
> local edit, incoming delete upon update
                 3 3 jrandom D
Status against revision: 3

$ svn resolve --accept=mine-full D/D1
Resolved conflicted state of 'D/D1'

$ svn st -vu D
A + - ? ? D/D1/delta
A + - 2 jrandom D/D1
                 3 3 jrandom D
Status against revision: 3
]]]

Then I attempt to commit:
[[[
$ svn ci -m '' D
[...]subversion/libsvn_client/commit.c:859: (apr_err=195002)
svn: Commit failed (details follow):
[...]subversion/libsvn_client/commit_util.c:1302: (apr_err=195002)
svn: Commit item 'D1' has copy flag but an invalid revision
]]]

But D1 doesn't appear to have an "invalid revision" (which, looking at
the code, refers to the copy-from revision):
[[[
$ svn info D/D1
Path: D/D1
URL: svn://localhost:33701/svn-test-work/repositories/update_tests-48/local_leaf_edit_incoming_tree_del/D/D1
Repository Root: svn://localhost:33701/svn-test-work/repositories/update_tests-48
Repository UUID: 85c025af-4c60-0410-bf4f-ad0e32091f23
Revision: 3
Node Kind: directory
Schedule: add
Copied From URL: svn://localhost:33701/svn-test-work/repositories/update_tests-48/local_leaf_edit_incoming_tree_del/D/D1
Copied From Rev: 2
Last Changed Author: jrandom
Last Changed Rev: 2
Last Changed Date: 2009-01-12 17:46:19 +0000 (Mon, 12 Jan 2009)
]]]

What's up? :-)

Alternative Implementation?
===========================

It has been crossing my mind that an alternative approach should be
possible: instead of tweaking the entries myself, call a higher-level
"add" API to schedule this existing stuff for addition. Not the plain
"add" but some kind of "add with history", and it would have to keep the
local state on disk of the files, and keep the properties that are still
there somehow in the metadata. I haven't explored this route, I just
mention it in case anyone says "ah, of course, that would be easy".

The attached patch represents the state of the issue-3334-dirs branch at
r35189.

- Julian

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