Re: how diff between hardlink trees works?

Sept. 10, 2011

      On 09/09/2011 12:39 PM, Vaibhav Jain wrote:
...
On Fri, Sep 9, 2011 at 11:12 AM, Kai Meyer <kai@gnukai.com 
<mailto:kai@gnukai.com>> wrote:
On 09/09/2011 09:05 AM, Vaibhav Jain wrote:
...
Hi,
I am not able to understand how diff between two trees of which
    one is just contains hardlinks to another's files (cp -al )ing
    works.I am asking this question here because I need to build a
    custom kernel for which I need to generate patch. So the
    documentation suggests to create a hardlink copy of the kernel
    source tree using cp -al and then make changes to
    one of the trees and run a diff.I am wondering that if files are
    hardlinks then changes to one copy will affect another in which case
    diff should give no output.
    Also, the patch I created looks a little odd as it contains
    complete modified files instead of just the differences.
    Please help!
Thanks
    Vaibhav Jain
_______________________________________________
    Kernelnewbies mailing list
    Kernelnewbies@kernelnewbies.org  <mailto:Kernelnewbies@kernelnewbies.org>
    http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Make the hard link copy like normal. Then delete the directory
    that you are making changes to (in the hard link directory), then
    copy the files over with out hard links. That way "most" of the
    kernel tree is hard linked, and just the portion you want to work
    on is a copy. That way the diff will work.
Otherwise, skip the hard link part all together, and just make a
    full copy. Uses lots of disk space and takes longer to diff.
-Kai Meyer
Hi Kai,
Thanks for the reply. I need just one more favour.
Could you please look at this document describing the procedure to build
custom fedora kernel. It mentions the step to create hardlink to 
generate but doesn't
talk about deleting anything ?I just need to confirm if the article is 
not accurate or if there is
any error in my understanding.
Whenever I follow it I get a patch that contains all of the content of 
the changed files rather than just the changes.
Here is the relevant portion :
Copy the Source Tree and Generate a Patch
This step is for applying a patch to the kernel source. If a patch is 
not needed, proceed to "Configure Kernel Options".
Copy the source tree to preserve the original tree while making 
changes to the copy:
cp -r ~/rpmbuild/BUILD/kernel-2.6.$ver.$fedver/linux-2.6.$ver.$arch ~/rpmbuild/BUILD/kernel-2.6.$ver$fedver.orig
cp -al ~/rpmbuild/BUILD/kernel-2.6.$ver.$fedver.orig ~/rpmbuild/BUILD/kernel-2.6.$ver.$fedver.new
*The second |cp| command hardlinks the |.orig| and |.new| trees to 
make |diff| run faster. Most text editors know how to break the 
hardlink correctly to avoid problems.*
Using vim on FC14, it treated the hard link as a hard link and thus 
the above technique failed. It was necessary to repeat the original 
copy used for the .orig directory for the .new directory. Note that 
this uses twice the space.
Make changes directly to the code in the |.new| source tree, or copy 
in a modified file. This file might come from a developer who has 
requested a test, from the upstream kernel sources, or from a 
different distribution.
After the |.new| source tree is modified, generate a patch. To 
generate the patch, run |diff| against the entire |.new| and |.orig| 
source trees with the following command:
cd ~/rpmbuild/BUILD
diff -uNrp kernel-2.6.$ver.$fedver.orig kernel-2.6.$ver.$fedver.new>  ../SOURCES/linux-2.6-my-new-patch.patch
Thanks
Vaibhav
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
The article says this:

"Using vim on FC14, it treated the hard link as a hard link and thus the 
above technique failed. It was necessary to repeat the original copy 
used for the .orig directory for the .new directory. Note that this uses 
twice the space."

It means to say that some editors, like VIM, edit files in-place, and 
some files copy the original contents into some other buffer (memory or 
temporary file), and then effectively delete the file you're editing, 
and copy the modified file into place. The hard-link instructions are a 
"trick" to save time and space when you are modifying large code base, 
like the kernel. If your favorite editor is behaving like the observed 
behavor of VIM, then you will need to delete the hard link file, and put 
a regular copy of the file in place before making changes.

-Kai Meyer