xfs
[Top] [All Lists]

Re: [PATCH] xfstests: more tests for test case btrfs/030

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfstests: more tests for test case btrfs/030
From: Filipe David Manana <fdmanana@xxxxxxxxx>
Date: Sun, 2 Feb 2014 22:08:06 +0000
Cc: xfs@xxxxxxxxxxx, "linux-btrfs@xxxxxxxxxxxxxxx" <linux-btrfs@xxxxxxxxxxxxxxx>, Josef Bacik <jbacik@xxxxxx>
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b0yF2Nl9SR1kF4yCoVH9Pb3qRsfzrzu4I1Mh5CMSeoc=; b=Jd7GkclqLrsolMZZOt/Fg8MVD5ebKHdONhsiS7FXyIXYICXtp09g9VZZGOcKB8HMfy IuxRKI54BwsYccLlJP7TKjDJ7iRyt8zkhBjn2EgO1234Qf1Pc1hsSLqZ814DaTz5wcUk +lQ1VvaSIZBRr1BIWOUO9WvPCjrDVn+0A+ZCBCtbMWCota7WqWBLoINJ/zDOPWZai+Z1 qbuhjbfyELuES7CoimzMjnJAGHHbolnR2ImRppnjdarr3NIEysfivSqtO0ldppAiHCcn q6nl1w5CvKrXfCwdtqAG2z78/M6zIlPje4VX3HLcZHgZihjel7PLJ65ClWDATjfA38OU eE/A==
In-reply-to: <20140202215720.GT2212@dastard>
References: <1391220332-22118-1-git-send-email-fdmanana@xxxxxxxxx> <20140202215720.GT2212@dastard>
Reply-to: fdmanana@xxxxxxxxx
On Sun, Feb 2, 2014 at 9:57 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
> On Sat, Feb 01, 2014 at 02:05:32AM +0000, 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 <fdmanana@xxxxxxxxx>
>
> 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
> david@xxxxxxxxxxxxx



-- 
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."

<Prev in Thread] Current Thread [Next in Thread>