I think we can all agree that when a user deletes part of their WC via the OS they have made a mistake of some sort. But which mistake exactly? The obvious answer is that they really intended 'svn del dirX/foo.c'. But possibly they intended something more akin to 'svn up --set-depth empty dirX'. Or maybe it was just a true mistake, and nothing was intended; they expect foo.c to be there!
I originally came to this question when dealing with merge tracking and paths missing because they were deleted outside of Subversion, see http://svn.haxx.se/dev/archive-2010-08/0156.shtml. Somewhat tardily I realized the *first* question to be answered is not how merge tracking should deal with such paths, but how should Subversion in general deal with them. I see a few basic approaches: 1) Consistent Approach -- Restore the Missing Paths (unless there is really a compelling reason not too, but the default approach is to restore) WCNG's single DB allows us to simply restore these missing paths as we encounter them (the notable exception being 'svn st' of course, which just reports the missing state). Exhibit A of this behavior: In 1.6.x and 1.7 in multiple DB mode, svn revert skips missing directories. In single-DB mode they are restored. 2) Consistent Approach: Error out If we detect missing paths, simply throw an error asking that the user restore them before proceeding. Obviously for svn st/up/revert, the current behavior is fine, but for svn ci/sw/merge we could follow this route. 3) Case-by-Case Approach: Maybe there is *no* consistent approach, and sometimes we will want to restore, but other times we'll do something else. I'll leave what "something else" is as an open question for the moment. Any ideas as to the best approach? I suspect that some of the wcng folks have given some thought to this. Paul
