"Bert Huijben" <b...@qqmail.nl> writes: >> -----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.
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
