Ben's thoughts: General problem we want to solve: When 'svn up' receives a copy or move (copy+delete), the existing locally-edited file should be copied (wc -> wc). (The status quo is to just delete (unversion) the edited file and add a wholly new file -- which greatly angers users.) Proposal: When driving the working copy update-editor, have the server send copyfrom-args in add_file() and add_dir(). - The copyfrom-path would be transmitted as an *absolute* fs path; it's up to the client to decide whether it has the path@rev available somewhere in its wc. - If the client doesn't have it, the client can do an extra RA request to fetch it. (i.e. we degrade to the status quo.) - If the server sends extra txdelta data, it would then be applied to the fulltext. Problem: What if the transmitted copyfrom-path is outside of the update's target-tree, i.e. the user updates only "one side" of a copy or move operation? (Example: user run 'svn update wc/B/', but the server wants to add a file that's copied from wc/A/?) Answer: No problem here. Even though the server has no idea whether or not the client has wc/A/ (the client only described a working copy rooted at wc/B/), the client can still have the 'smarts' to locate the root of its working copy, and figure out if it has the copyfrom path or not. Problem: Server wants to transmit a move operation. What if it transmits a delete before it transmits a copy operation? (This can happen because trees are always crawled depth-first.) Then the client may not have the file anymore (or it may have become unversioned). Answer: If the source of the copy is truly gone, the client can do an extra RA request to fetch it. (We degrade to the status quo; it's just bad luck.) If the source of the copy had local edits, then it's not actually gone; the deletion has caused it to become either unversioned (status quo) or schedule-add-with-history (cmpilato's proposed new tree-conflict behavior.) Assuming we implement the latter behavior, we'll still have an edited file we can copy.