RFC: How should Subversion handle OS-deleted paths?

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
Received on 2010-08-20 20:05:21 CEST