notes/copies-during-updates.txt

   1
   2 Ben's thoughts:
   3
   4
   5 General problem we want to solve:
   6
   7   When 'svn up' receives a copy or move (copy+delete), the existing
   8   locally-edited file should be copied (wc -> wc).  (The status quo is
   9   to just delete (unversion) the edited file and add a wholly new file
  10   -- which greatly angers users.)
  11
  12
  13 Proposal:
  14
  15   When driving the working copy update-editor, have the server send
  16   copyfrom-args in add_file() and add_dir().
  17
  18    - The copyfrom-path would be transmitted as an *absolute* fs path;
  19      it's up to the client to decide whether it has the path@rev
  20      available somewhere in its wc.
  21
  22    - If the client doesn't have it, the client can do an extra RA
  23      request to fetch it.  (i.e. we degrade to the status quo.)
  24
  25    - If the server sends extra txdelta data, it would then be applied
  26      to the fulltext.
  27
  28
  29 Problem:
  30
  31    What if the transmitted copyfrom-path is outside of the update's
  32    target-tree, i.e. the user updates only "one side" of a copy or
  33    move operation?  (Example: user run 'svn update wc/B/', but the
  34    server wants to add a file that's copied from wc/A/?)
  35
  36
  37 Answer:
  38
  39    No problem here.  Even though the server has no idea whether or not
  40    the client has wc/A/ (the client only described a working copy
  41    rooted at wc/B/), the client can still have the 'smarts' to locate
  42    the root of its working copy, and figure out if it has the copyfrom
  43    path or not.
  44
  45
  46 Problem:
  47
  48    Server wants to transmit a move operation.  What if it transmits a
  49    delete before it transmits a copy operation?  (This can happen
  50    because trees are always crawled depth-first.)  Then the client may
  51    not have the file anymore (or it may have become unversioned).
  52
  53
  54 Answer:
  55
  56    If the source of the copy is truly gone, the client can do an extra
  57    RA request to fetch it.  (We degrade to the status quo; it's just
  58    bad luck.)
  59
  60    If the source of the copy had local edits, then it's not actually
  61    gone; the deletion has caused it to become either unversioned
  62    (status quo) or schedule-add-with-history (cmpilato's proposed new
  63    tree-conflict behavior.)   Assuming we implement the latter
  64    behavior, we'll still have an edited file we can copy.
  65