--keep-local and properties

(Note, this is a different issue to the one pburba, Stefan Küng and me were
discussing in another thread)

Hi all,

I'd like confirmation from the community for a theoretical issue. It's
saturday, no replies on #svn-dev :)

$ svn delete ./dir --keep-local

This leaves the data in the file system after removing the items from
version control.

Another side effect is that svn no longer checks whether there are any local
modifications. The rationale is: we're going to keep everyting in the
filesystem anyway, so don't bother the user anymore.

Now, I have a problem with this: It only keeps *text* modifications on disk.
All *property* modifications are lost without a warning.

Properties may hold important data, I'm thinking e.g. of "svn:externals".

So, please tell me I'm right in following this path:
Upon `svn delete ./dir --keep-local':

(1) If there are only local text modifications, act as before. Remove from
version control, leave on disk.

(2) If there are local prop modifications, fail with an error similar to
when `--keep-local' were not supplied, but be specific about properties:
"svn: 'dir' has local property modifications -- commit or revert them first"

(3) Feature: add an option to `svn revert' that allows only reverting
property mods (doesn't exist yet AFAICT).

If I were to implement (2), I'd modify the signature of
svn_client__can_delete().

I'd like to even make it entirely private to that file. I can see only one
(local) caller of this function today, and libsvn_client/copy.c
(wc_to_wc_copy) used to use it as well until r21347.

Could this be used to publish client API to third-party elements? How do I
find out?
...would this thus become an svn_client__can_delete2()? Do we do that with
private API?

`make check' is successful if I rename this function and make it static and
private to libsvn_client/delete.c. So I'm tempted to go that way.

(If all above makes sense, that is.)

Thanks for any comments,
~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2359995