"Bert Huijben" <bert_at_qqmail.nl> writes:
>> -----Original Message-----
>> From: MARTIN PHILIP [mailto:codematters_at_ntlworld.com] On Behalf Of
>> Philip Martin
>> Sent: donderdag 4 april 2013 13:19
>> To: dev_at_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.
The fact that delete is a WORKING node shadowing a BASE node is an
artifact of the implementation. As far as the user is concerned the only
node is the deleted repository node and that is switched. I think we
should be showing the switched status in this case.
It's different if the user copies a tree into the working copy. The
copied WORKING nodes are not in the repository and not being able to
switch a subtree is OK in that case.
> (For deletes I can see the switch reporting might make sense... But then you
> get into the replacement story)
Replace does complicate things
1.6) status: R and S, commit: switched URL
1.7) status: R, commit: unswitched URL
1.8) status: R, commit: unswitched URL
So 1.7 commit affects the switched URL for deletes and the unswitched
URL for replaces. That's just awful.
The 1.6 behaviour looks reasonable: status shows S and commit replaces
the switched URL.
> 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.
I think we should be showing the switch and so deleting the unswitched
URL is wrong.
> 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.
1.6 replaces the switched URL. As far as I can see 1.6 has resonable
behaviour from a user's point of view. The file is marked switched the
commit affects the switched item. Even update after committing the
delete or replace seems to work: for replace the item remains switched,
for delete the switched item is removed from the working copy and update
restores the unswitched item.
> Deleting the unswitched URL has problems on the delete side...
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2013-04-04 14:23:55 CEST