On Sat, Jun 6, 2009 at 8:36 PM, Neels Janosch Hofmeyr<neels_at_elego.de> wrote:
> 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.)
Hi Neels,
I understand the problem you are describing, though I wonder if this
is something anyone is actually asking for. That said, your first two
ideas for dealing with local prop changes and 'svn del --keep-local'
seem sound:
> (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"
Instead of (3) maybe make using --force in conjunction with
--keep-local will work as --keep-local alone does today, i.e. text
changes and directory structures intact, but prop changes (obviously)
gone.
> (3) Feature: add an option to `svn revert' that allows only
> reverting property mods (doesn't exist yet AFAICT).
> Further limitation: only error out if there are non-mergeinfo changes -- but
> may mergeinfos in particular be important to catch sometimes?
I don't think we'd ever care about losing mergeinfo on a path we are
deleting, since the mergeinfo is describing merges to *that* path. So
ignoring mergeinfo changes is safe IMO. But is it really necessary to
special case this? I'm under the impression that the overall use case
here is already quite rare, so this special case might be overkill.
Paul
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360642
Received on 2009-06-09 16:00:11 CEST