On Tue, 2010-09-14, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Sat, Sep 11, 2010 at 00:02:16 +0200:
> > On Fri, Sep 10, 2010 at 11:45 PM, <johanco_at_tigris.org> wrote:
> > > http://subversion.tigris.org/issues/show_bug.cgi?id=3474
> > >
> > > ------- Additional comments from johanco_at_tigris.org Fri Sep 10 14:45:17 -0700 2010 -------
> > > This issue seems to be fixed on trunk. The described scenario now goes as follows:
> > >
> > > (assuming we're in a working copy with a versioned file a.txt)
> > > [[[
> > > $ svn mkdir subdir
> > > A subdir # same as in 1.6
> > >
> > > $ svn mv a.txt subdir
> > > A subdir\a.txt
> > > D a.txt # same as in 1.6
> > >
> > > $ svn st
> > > A subdir
> > > A + subdir\a.txt
> > > D a.txt # same as in 1.6
> > >
> > > $ svn mv subdir subdir2
> > > A subdir2
> > > D subdir\a.txt
> > > D subdir # different! will ask on dev list about this.
> >
> > Is the above output an expected change of behavior?
I believe that's a bug. It should display the same as it did in 1.6,
unless and until we decide to change it.
Do we have any test for this?
> Previously (in
> > 1.6) the above action generated the following output (as can be seen
> > in the original description of issue 3474):
> >
> > [[[
> > $ svn mv subdir/ subdir2
> > A subdir2
> > A subdir2\a.txt
> > D subdir
> > ]]]
> >
> > It's no problem for me (the result is perfectly fine), just wondering ...
> >
> > In fact, I never quite understood the output in 1.6 (why are all
> > children of a moved directory shown as deleted, and not as added in
> > the new dir?). But I don't understand it now either (I can reverse the
> > question).
>
> The other way around, right? What you describe here as 1.6's behaviour
> is in fact 1.7's behaviour (and vice-versa)...
>
> > Is there any rational explanation, any underlying
> > reasoning, principles, ... ?
It all stems from the fact that 1.6 treats a move as a delete and an
add.
> When a directory is removed, then everything under it (all children and
> descendants) implicitly ceases to exist too. (Consider the grandfather
> paradox.) So I can see the 'D subdir/a.txt' notification as redundant.
Yup, so a single line 'D subdir' was chosen as the notification for a
simple delete.
> On the other hand, after the move two new nodes exist: 'subdir2/' and
> 'subdir2/a.txt'. So it would be appropriate to generate notifications
> that allow the client to infer that both of them exist.
The point is that, in a simple add, the creation of any children can't
be inferred from the creation of the parent.
For a move, 1.6 simply combines the 'simple delete' and 'simple add'
notifications. This means we get notifications about the children even
though that is not useful.
At some point we will want to change the 'move' notifications to be more
in line with 'atomic rename' semantics rather than a delete and an add.
The children should not be mentioned at all; the only useful information
is the renaming and/or moving of the target node itself.
- Julian
Received on 2010-09-14 11:57:44 CEST