Mark Phippard wrote:
> 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
No, file contents are handled fine. My argument revolves around not wanting
to lose local mods to *properties*... (s.b.)
>
>
> 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.
...here, this ^^^ is my problem. If I have a file or dir, and I do some `svn
propset' locally, or a merge does them, for that matter (not talking about
mergeinfo, but about actual user supplied props).
If I then call `svn delete --keep-local', it will remove from version
control and keep the text file content and dir structure, but it will *not*
be able to keep the properties' values.
In other words, even though they are not file content changes, real changes
a user made are lost without a warning.
So the argument goes:
>>
>> 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"
Further limitation: only error out if there are non-mergeinfo changes -- but
may mergeinfos in particular be important to catch sometimes?
>>
>> (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=2360031
Received on 2009-06-07 02:37:26 CEST