| |
| Directory copies -- How They Work |
| |
| |
| What happens now, when you type "svn cp dir1 dir2": |
| |
| * dir1 is copied recursively via APR IO routines (equivalent to a |
| unix 'cp -R dir1 dir2') |
| |
| * dir2 is scheduled for addition in both parent and its own |
| 'this_dir' entry, ** with copyfrom args **. |
| |
| * dir2's ancestor URL is rewritten, as is the ancestor URL of |
| *every* child. (recursively). We do this because it's the normal |
| expected behavior; whenever we schedule anything for addition, the |
| new entry receives a "predicted" URL that doesn't really exist |
| yet. |
| |
| * during commit, the commit-crawler correctly sends copyfrom args to |
| editor, and svn_fs_copy is called, and then crawler recurses *not* |
| in funky 'adds-only' mode (so it can still detect local mods) |
| |
| * after commit succeeds, any directory "target" that was added with |
| history has ALL of its children recursively revision-bumped. |
| |
| |
| What still needs to happen: |
| |
| * crawler: if existence==copied, report differing revisions! |
| (compare entry->rev against parent_stackframe->entry->rev.) |
| |
| * post-commit: how to deal with deletes within a copied directory? |
| |
| svn_wc_set_revision is told to do a recursive bump. |
| it calls log_do_committed, which is supposed to recognize a |
| "schedule delete", no? and remove it from version control? |
| |