'svn resolved' (past tense) actually performs resolution now?

I was surprised today to find that 'svn resolved' (so named with a
past-tense verb explicitly because we wanted users to understand that it
doesn't actually itself perform resolution steps) accepts the --accept
option and now *does* perform resolution steps. This despite still claiming
in its usage message:

$ svn help resolved
resolved: Remove 'conflicted' state on working copy files or directories.
usage: resolved PATH...

   Note: this subcommand does not semantically resolve conflicts or
   remove conflict markers; it merely removes the conflict-related
   artifact files and allows PATH to be committed again.

...

I suggested in IRC that this is somewhat confusing for users, who might be
led to think that they now need to tell 'svn resolved' *how* they resolved
conflicts, with the result being that 'svn resolved' will then try to
perform said resolution again, possibly resulting in errors or -- worse --
in wasted conflict resolution efforts. I'd rather see a new subcommand 'svn
resolve' for this active behavior, and retain 'svn resolved' for the passive
work it has always performed.

Eric Gillespie seemed to agree, noting that he envisions an 'svn resolve'
subcommand that can do the full range of interactive conflict resolution
magic someday (which gets a hearty +1 from me), but his initial willingness
to bifurcate today's 'resolved' subcommand was doused by Mark Phippard's
insistence that all is well (or at least well enough) with the UI as it is
today.

What do others think?

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand