[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Status of children of replaced directories

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Fri, 12 Nov 2010 13:29:30 +0000

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
Received on 2010-11-12 14:30:14 CET

This is an archived mail posted to the Subversion Dev mailing list.