copy-planz.txt

Ben and I are pretty much fielding the bulk of the `svn cp' and `svn
mv' commands. He's done a huge chunk already, working out many of the
nuances of what it means to do a copy on the working copy side of
things. I've excitedly claimed the task of handling all the
copy-related stuff that happens outside the working copy. My
thoughts/plans are below.

There are all kinds of little nuances involved in this stuff, and all
kinds of considerations I'm making regarding how to factorize code so
that it's maintainable and yet usable. This will probably result in
the 27th rewrite of the commit crawler, but we'll see.

Anyway, these are my plans thus far. Feedback *about the planz* (If
you have complaints or suggestions about the API, start a different
thread, please) is welcome (and expected, darnit!).

----
Here's the generic routine for accomplishing a copy/move given two
paths.  It was comforting to find, after I had worked out this
algorithm, that Ben had done pretty much exactly this already in
svn_client_copy().
   if (not exist src_path)
     return ERR_BAD_SRC error
   if (exist dst_path)
     {
       if (dst_path is directory)
         copy src_path into dst_path as basename (src_path)
       else
         return ERR_OBSTRUCTION error
     }
   else
     {
       if (not exist parent_of_dst_path)
         return ERR_BAD_DST error
       else
         copy src_path into parent_of_dst_path as basename (dst_path)
     }
   if (this is a move)
     delete src_path
   
----
Here is how I plan to handle the four basic cases for `svn copy/move',
as determined by the type of paths supplied as the SRC and DST
arguments to the copy command.
* Case I - SRC is working copy path, DST is working copy path:
   I don't care about it.  Ben Collins-Sussman is handling that. :-)
* Case II - SRC is working copy path, DST is repository URL:
   To accomplish this operation, we drive the commit crawler/editor in
   pretty much the same way we would if performing an import, except
   we are using an existing working copy to determine the items being
   imported instead of disk dirents.  All items in SRC tree are added,
   either implicitly (as a side effect of their parents having been
   added) or explicitly (at the top of the SRC tree, or because they
   have a different revision from that of their parent).  Also, local
   modifications to items in SRC are transmitted as part of the commit
   as well.
   If this a `move' operation, SRC (or, the URL associate with SRC in
   the repository) will be deleted as part of the commit process.
   The working copy is never modified during this process is this is a
   `copy'.  For `move's, we *could* go ahead and remove SRC in the
   working copy, but I'm planning to just take the easy route for now
   and require the user to update.  I'd like to keep this a WC-free
   operation.
* Case III - SRC is repository URL, DST is working copy path:
   There are two routes to take with this:
   - Treat this as a Case IV (using DST's constructed repository URL)
     plug a checkout of DST, or
   - Treat this is a special checkout of SRC (at the optionally supplied
     revision, even), except that once the checkout is complete, you
     have DST scheduled for commit as a copy.
   I personally like the former, seems cleaner to me, and it allows
   `move's to happen atomically.
* Case IV - SRC is repository URL, DST is repository URL:
   This is a freaky special commit drive, where we operate purely on
   our ability to split paths up into components, and then "crawl"
   those trees based purely on the layout of those path components.
   Actually, for copies this is pretty much a four-line commit:
      e->replace_root (dst)
      e->add_(file/dir) (dst_basename, copyfrom=src)
      e->close_dir
      e->close_edit
   The part that requires all the path component attention is if this
   is a move, because we have make sure to anchor the edit at the
   longest common ancestor of SRC and DST so we can delete SRC as part
   of the same transaction as our addition of DST.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org