Can you explain more why you think the command should fail? The way I
see it, there is little difference between svn delete with our without
the --keep-local option. In either case you are telling SVN to no
longer version the item and are scheduling it for delete. On the next
commit the item will be deleted from the repository. The only
difference is that the file will be left in your working copy. Other
users that update will have the file removed from their working copy.
If a file is unversioned it cannot have SVN properties. So I do not
see how that factors in, but perhaps you are thinking of something
more subtle? Such as what happens if you update when one of these
files is schedule for delete and the update bring in changes?
Mark
On Sat, Jun 6, 2009 at 1:09 PM, Neels Janosch Hofmeyr<neels_at_elego.de> wrote:
> (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
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360019
Received on 2009-06-07 00:14:27 CEST