Re: [PATCH] xfstests: more tests for test case btrfs/030
On Sat, Feb 01, 2014 at 02:05:32AM +, Filipe David Borba Manana wrote: This change adds some new tests for btrfs' incremental send feature. These are all related with inverting the parent-child relationship of directories, and cover the cases: * when the new parent didn't get renamed (just moved) * when a child file of the former parent gets renamed too These new cases are fixed by the following btrfs linux kernel patches: * Btrfs: more send support for parent/child dir relationship inversion * Btrfs: fix send dealing with file renames and directory moves Signed-off-by: Filipe David Borba Manana fdman...@gmail.com Rather than modifying 030 which will cause it to fail on kernels where it previously passed, can you factor out the common code and create a new test with the additional coverage? i.e. the rule of thumb is that once a test is done we don't go back and modify it in significant ways - we write a new unit test that covers the new/extended functionality. Redundancy in unit tests is not a bad thing... Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfstests: more tests for test case btrfs/030
On Sun, Feb 2, 2014 at 9:57 PM, Dave Chinner da...@fromorbit.com wrote: On Sat, Feb 01, 2014 at 02:05:32AM +, Filipe David Borba Manana wrote: This change adds some new tests for btrfs' incremental send feature. These are all related with inverting the parent-child relationship of directories, and cover the cases: * when the new parent didn't get renamed (just moved) * when a child file of the former parent gets renamed too These new cases are fixed by the following btrfs linux kernel patches: * Btrfs: more send support for parent/child dir relationship inversion * Btrfs: fix send dealing with file renames and directory moves Signed-off-by: Filipe David Borba Manana fdman...@gmail.com Rather than modifying 030 which will cause it to fail on kernels where it previously passed, can you factor out the common code and create a new test with the additional coverage? i.e. the rule of thumb is that once a test is done we don't go back and modify it in significant ways - we write a new unit test that covers the new/extended functionality. Redundancy in unit tests is not a bad thing... Right. The only reason I did this, instead of a new test file, is that because the former fix which btrfs/030 relates to is not yet in any kernel release. Given this fact, what do you think? thanks Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- Filipe David Manana, Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xfstests: more tests for test case btrfs/030
On Sun, Feb 02, 2014 at 10:08:06PM +, Filipe David Manana wrote: On Sun, Feb 2, 2014 at 9:57 PM, Dave Chinner da...@fromorbit.com wrote: On Sat, Feb 01, 2014 at 02:05:32AM +, Filipe David Borba Manana wrote: This change adds some new tests for btrfs' incremental send feature. These are all related with inverting the parent-child relationship of directories, and cover the cases: * when the new parent didn't get renamed (just moved) * when a child file of the former parent gets renamed too These new cases are fixed by the following btrfs linux kernel patches: * Btrfs: more send support for parent/child dir relationship inversion * Btrfs: fix send dealing with file renames and directory moves Signed-off-by: Filipe David Borba Manana fdman...@gmail.com Rather than modifying 030 which will cause it to fail on kernels where it previously passed, can you factor out the common code and create a new test with the additional coverage? i.e. the rule of thumb is that once a test is done we don't go back and modify it in significant ways - we write a new unit test that covers the new/extended functionality. Redundancy in unit tests is not a bad thing... Right. The only reason I did this, instead of a new test file, is that because the former fix which btrfs/030 relates to is not yet in any kernel release. Given this fact, what do you think? Ok, so if it already fails for everyone, then I think we'll be fine to modify it like this. done is a flexible concept when it comes to unit tests ;) Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
