You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Johan Corveleyn <jc...@gmail.com> on 2010/09/10 22:02:16 UTC
Re: [Issue 3474] making a new subdir, moving files into it and then
renaming the subdir, breaks history of the moved files
On Fri, Sep 10, 2010 at 11:45 PM, <jo...@tigris.org> wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=3474
>
> ------- Additional comments from johanco@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? 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). Is there any rational explanation, any underlying
reasoning, principles, ... ?
Cheers,
--
Johan
Re: [Issue 3474] making a new subdir, moving files into it and then renaming the subdir, breaks history of the moved files
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
>> -----Original Message-----
>> From: Philip Martin [mailto:philip.martin@wandisco.com]
>>
>> Perhaps we should simply notify for all nodes? Perhaps each
>> individual client should be deciding which notifications to suppress?
>
> +1 on moving the choice to the clients. (svn has different requirements then
> clients like Subclipse).
>
> Personally (and for AnkhSVN) I don't have an issue with notifying adds and
> deletes for the root only. (The fact that it is an add or delete tells that
> it's operation changes the state of all descendants)
Root-only delete notification is much easier to implement in the
library than in the client. That's because delete notifications for
children tend to happen before the parent, and the application has to
be organised to allow it to determine that a child will be followed by
a parent.
--
Philip
RE: [Issue 3474] making a new subdir, moving files into it and then renaming the subdir, breaks history of the moved files
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Philip Martin [mailto:philip.martin@wandisco.com]
> Sent: woensdag 15 september 2010 12:08
> To: Julian Foad
> Cc: Daniel Shahaf; Johan Corveleyn; Subversion Development
> Subject: Re: [Issue 3474] making a new subdir, moving files into it and
> then renaming the subdir, breaks history of the moved files
>
> Julian Foad <ju...@wandisco.com> writes:
>
> > 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, <jo...@tigris.org> wrote:
> >> > > http://subversion.tigris.org/issues/show_bug.cgi?id=3474
> >> > >
> >> > > ------- Additional comments from johanco@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.
>
> The notification rules for 1.6 are a bit haphazard, I suspect some of
> the behaviour is not the result of deliberate decisions but simply a
> consequence of the way the code is structured.
>
> For example, in 1.6 move/delete notifies deletes for all nodes in a
> tree, apart from nodes within an added directory. There is no reason
> for that, beyond it being the way the code is written.
>
> For moves/copies the add notification is for all nodes in a tree apart
> from nodes within a copy source directory that is normal or copied.
> (I may not have got that exactly right!)
>
> These rules are not documented as far as I can see, so the question is
> whether we have to maintain this arbitrary behaviour.
>
> Perhaps we should simply notify for all nodes? Perhaps each
> individual client should be deciding which notifications to suppress?
+1 on moving the choice to the clients. (svn has different requirements then
clients like Subclipse).
Personally (and for AnkhSVN) I don't have an issue with notifying adds and
deletes for the root only. (The fact that it is an add or delete tells that
it's operation changes the state of all descendants)
Bert
Re: [Issue 3474] making a new subdir, moving files into it and then renaming the subdir, breaks history of the moved files
Posted by Philip Martin <ph...@wandisco.com>.
Julian Foad <ju...@wandisco.com> writes:
> 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, <jo...@tigris.org> wrote:
>> > > http://subversion.tigris.org/issues/show_bug.cgi?id=3474
>> > >
>> > > ------- Additional comments from johanco@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.
The notification rules for 1.6 are a bit haphazard, I suspect some of
the behaviour is not the result of deliberate decisions but simply a
consequence of the way the code is structured.
For example, in 1.6 move/delete notifies deletes for all nodes in a
tree, apart from nodes within an added directory. There is no reason
for that, beyond it being the way the code is written.
For moves/copies the add notification is for all nodes in a tree apart
from nodes within a copy source directory that is normal or copied.
(I may not have got that exactly right!)
These rules are not documented as far as I can see, so the question is
whether we have to maintain this arbitrary behaviour.
Perhaps we should simply notify for all nodes? Perhaps each
individual client should be deciding which notifications to suppress?
--
Philip
Re: [Issue 3474] making a new subdir, moving files into it and
then renaming the subdir, breaks history of the moved files
Posted by Julian Foad <ju...@wandisco.com>.
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, <jo...@tigris.org> wrote:
> > > http://subversion.tigris.org/issues/show_bug.cgi?id=3474
> > >
> > > ------- Additional comments from johanco@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
Re: [Issue 3474] making a new subdir, moving files into it and
then renaming the subdir, breaks history of the moved files
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Sat, Sep 11, 2010 at 00:02:16 +0200:
> On Fri, Sep 10, 2010 at 11:45 PM, <jo...@tigris.org> wrote:
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3474
> >
> > ------- Additional comments from johanco@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? 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, ... ?
>
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.
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.
There are several options to do that: perhaps 'A + subdir2/' or (more
accurately) 'A subdir2/ has_children=True', or 'A subdir2/; A subdir2/a.txt'.
> Cheers,
> --
> Johan
Re: [Issue 3474] making a new subdir, moving files into it and
then renaming the subdir, breaks history of the moved files
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Johan Corveleyn wrote on Sat, Sep 11, 2010 at 00:02:16 +0200:
> On Fri, Sep 10, 2010 at 11:45 PM, <jo...@tigris.org> wrote:
> > http://subversion.tigris.org/issues/show_bug.cgi?id=3474
> >
> > ------- Additional comments from johanco@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? 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, ... ?
>
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.
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.
There are several options to do that: perhaps 'A + subdir2/' or (more
accurately) 'A subdir2/ has_children=True', or 'A subdir2/; A subdir2/a.txt'.
> Cheers,
> --
> Johan