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