> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: donderdag 4 april 2013 13:19
> To: dev@subversion.apache.org
> Subject: issue 4345: switch/delete/commit confusion
>
> Prompted by a question on users:
> http://subversion.tigris.org/issues/show_bug.cgi?id=4345
>
> - switch a file
> - delete the switched file
> - run status/info
> - commit
>
> The behaviour varies with client version:
>
> 1.6) status: D and S, info: switched URL, commit: switched URL.
>
> 1.7) status: D, info: switched URL, commit: switched URL.
>
> 1.8) status: D, info: switched URL, commit: unswitched URL.
>
> What should happen?
First for status: With WC-NG we decided that WORKING nodes can't be
switched. (see design).
So once a BASE node is shadowed by a WORKING node we don't show it as
switched.
So while this is a behavior change in 1.7 I think it is a good one. The
actual node in the working copy is not switched.
(For deletes I can see the switch reporting might make sense... But then you
get into the replacement story)
Then the delete part:
The behavior here is not strictly defined, but we have a behavior change.
As we don't report the node as switched, you would be surprised if the
switched URL would be deleted.
We don't know if an unswitched URL exists, so deleting that might show other
problems.
As a clear solution I would say: handle switched nodes like file externals
and deny explicitly scheduling them for delete.
(I don't see a problem with scheduling an ancestor of a switched node for
delete)
Deleting the switched URL, makes replacing the node impossible: the original
node still exists, while we would apply an add after the delete.
Deleting the unswitched URL has problems on the delete side...
So, the easy way out would be to error when 'svn rm'-ing a switched node.
Bert
