> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematt...@ntlworld.com] On Behalf Of
> Philip Martin
> Sent: donderdag 4 april 2013 14:23
> To: Bert Huijben
> Cc: 'Philip Martin'; dev@subversion.apache.org
> Subject: Re: issue 4345: switch/delete/commit confusion
>
> "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.
While this might be/sound reasonable, this is not how
svn_wc__db_scan_addition() and everything build on top works.
Added nodes are in WC-NG always added below their parent; they don't have a
URL. What is below an added tree is completely ignored for its status
Changing this, changes the entire WC-NG design in many more ways than I can
think of...
Bert
