copies-during-updates.txt [plain text]
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.)
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.
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/?)
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.
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).
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
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.