Re: [Issue 3474] making a new subdir, moving files into it and then renaming the subdir, breaks history of the moved files
Julian Foad julian.f...@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, joha...@tigris.org wrote: http://subversion.tigris.org/issues/show_bug.cgi?id=3474 --- Additional comments from joha...@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
-Original Message- From: Philip Martin [mailto:philip.mar...@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 julian.f...@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, joha...@tigris.org wrote: http://subversion.tigris.org/issues/show_bug.cgi?id=3474 --- Additional comments from joha...@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
Bert Huijben b...@qqmail.nl writes: -Original Message- From: Philip Martin [mailto:philip.mar...@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
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, joha...@tigris.org wrote: http://subversion.tigris.org/issues/show_bug.cgi?id=3474 --- Additional comments from joha...@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
Johan Corveleyn wrote on Sat, Sep 11, 2010 at 00:02:16 +0200: On Fri, Sep 10, 2010 at 11:45 PM, joha...@tigris.org wrote: http://subversion.tigris.org/issues/show_bug.cgi?id=3474 --- Additional comments from joha...@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
On Fri, Sep 10, 2010 at 11:45 PM, joha...@tigris.org wrote: http://subversion.tigris.org/issues/show_bug.cgi?id=3474 --- Additional comments from joha...@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
