[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: --keep-local and properties

From: Neels Janosch Hofmeyr <neels_at_elego.de>
Date: Sun, 07 Jun 2009 02:36:31 +0200

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,


Received on 2009-06-07 02:37:26 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.