Paul Burba wrote:
> 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
I'm specifically thinking of svn:externals, actually. An svn:externals prop
possibly holds information that is vital to some production release. When
the revision numbers are fixed, it could determine which revision is the
actual stable one etc., and it also determines the directory subtree loaded
into working copies (when externals are used).
If corporate users were to go about employing externals extensively, they
would be terrified by having their important working copy tree seen as not
important enough to keep safe.
Possibly, there are other props with similar implications?
> 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"
ok, cool.
>
> 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.
With text mods, --keep-local currently sort of implies --force. I also
remember some argument about not overloading --force too much with different
meanings. However, in this case, I guess it *does* make sense.
I'll make a test / issue / fix soon.
Thanks,
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2360689
Received on 2009-06-09 19:01:41 CEST