Status of children of replaced directories

[Philip Martin <ph...@wandisco.com>]

Suppose I have a checkout containing a versioned directory A that
contains a child A/f.  If I delete A the status shows:

$ svn st 
D   A
D   A/f

If I now copy some other directory to replace A and the copied directory
also has a child f, then status shows:

$ svn st
R + A

That looks correct to me, the replacement hides the deleted child.  If
the copied directory also contains a child g and I delete it within the
copy, then status shows

$ svn st
R + A
D   A/g

which also looks correct.

However if the copied directory does not contain a child f then the
status of the deleted A/f shows through after the replacement:

$ svn st
R + A
D   A/f

and if I delete the copied child g then status shows:

$ svn st
R + A
D   A/f
D   A/g

I think both of those are wrong, the deleted A/f should be hidden by the
replacement.  The delete of A/f is fundamentally different to the delete
of A/g.  On commit the client will delete A, copy the replacement and
delete A/g; it won't delete A/f.

Anybody want to agree or disagree?

-- 
Philip

Re: Status of children of replaced directories

[Julian Foad <ju...@wandisco.com>]

On Fri, 2010-11-05, Stefan Sperling wrote:
> On Tue, Nov 02, 2010 at 04:28:59PM +0000, Philip Martin wrote:
> > Suppose I have a checkout containing a versioned directory A that
> > contains a child A/f.  If I delete A the status shows:
> > 
> > $ svn st 
> > D   A
> > D   A/f
> > 
> > If I now copy some other directory to replace A and the copied directory
> > also has a child f, then status shows:
> > 
> > $ svn st
> > R + A
> > 
> > That looks correct to me, the replacement hides the deleted child.  If
> > the copied directory also contains a child g and I delete it within the
> > copy, then status shows
> > 
> > $ svn st
> > R + A
> > D   A/g
> > 
> > which also looks correct.
> > 
> > However if the copied directory does not contain a child f then the
> > status of the deleted A/f shows through after the replacement:
> > 
> > $ svn st
> > R + A
> > D   A/f
> > 
> > and if I delete the copied child g then status shows:
> > 
> > $ svn st
> > R + A
> > D   A/f
> > D   A/g
> > 
> > I think both of those are wrong, the deleted A/f should be hidden by the
> > replacement.  The delete of A/f is fundamentally different to the delete
> > of A/g.  On commit the client will delete A, copy the replacement and
> > delete A/g; it won't delete A/f.
> > 
> > Anybody want to agree or disagree?
> 
> I agree. The deletion of A/f should now show through.

(Presumably meant "should not show through".)

I agree too.

I wondered if there are other cases which we need to bring into line
with this thinking.  For example, does it really make sense to continue
to show all the children of a simple delete:

  D   A
  D   A/f

if we agree that we should suppress them when there's a replacement?  In
one sense, yes it does - "show me the topmost local change".  Actually,
I can't currently see any counter-argument or inconsistency, so that's
fine.

- Julian

Re: Status of children of replaced directories

[Stefan Sperling <st...@elego.de>]

On Tue, Nov 02, 2010 at 04:28:59PM +0000, Philip Martin wrote:
> Suppose I have a checkout containing a versioned directory A that
> contains a child A/f.  If I delete A the status shows:
> 
> $ svn st 
> D   A
> D   A/f
> 
> If I now copy some other directory to replace A and the copied directory
> also has a child f, then status shows:
> 
> $ svn st
> R + A
> 
> That looks correct to me, the replacement hides the deleted child.  If
> the copied directory also contains a child g and I delete it within the
> copy, then status shows
> 
> $ svn st
> R + A
> D   A/g
> 
> which also looks correct.
> 
> However if the copied directory does not contain a child f then the
> status of the deleted A/f shows through after the replacement:
> 
> $ svn st
> R + A
> D   A/f
> 
> and if I delete the copied child g then status shows:
> 
> $ svn st
> R + A
> D   A/f
> D   A/g
> 
> I think both of those are wrong, the deleted A/f should be hidden by the
> replacement.  The delete of A/f is fundamentally different to the delete
> of A/g.  On commit the client will delete A, copy the replacement and
> delete A/g; it won't delete A/f.
> 
> Anybody want to agree or disagree?

I agree. The deletion of A/f should now show through.