Monday, February 13, 2012

Playing With Patches

For this assignment, we were to read chapter 7 and do some of the problems contained within it.  The title of the chapter is "Fixing_The_Code" and talks about how to document and submit bug fixes.  The first thing that struck me after reading this chapter was how well implemented a process this is.  And also that it was completely different from how I imagined it.

When I thought about fixing bugs and then submitting them for approval from the project developers, I figured that you just uploaded the patch into the repository.  Then the code update would happen after the patch was reviewed by the People In Charge.  Well, it seems that there is a bit more to the process than that.  There is a really neat way that the fix is documented that makes whatever changes made easy to read, and keeps things standardized across the board.  This is called creating a diff, or patch.

The patch is a text file that is created by comparing two (or more) other files using the unix diff command, then piping the results of that comparison into the text file.  The example in the book starts with a simple C
program:

#include <stdio.h>

int main() {
     printf("hello, world.\n");
     return 0;
{
    
Now, say you want to change the code to express your insane enthusiasm for C and programming in general.  In order to do so, you must create a patch file.  The first thing to do is make a copy of the "hello.c" file in the same directory.  Then make the changes to the original file, namely some exclamation points:

#include <stdio.h>


int main() {
     printf("hello, world!!!\n");
     return 0;
{

Now to create the patch.  A simple command takes care of the rest:

$ diff hello.c.new hello.c > crazyHello.patch

This compared the two files, documented the changes, and reported them into the file "crazyHello.patch".  This file has a lot of information in it, but the most important is what was actually changed.  It looks like this:

-    printf("hello, world.\n");
+   printf("hello, world!!!\n");

By doing things this way, open source developers know exactly what to look for when a patch is uploaded to them. This makes things go a lot faster for approving changes, fixing bugs for users, and improving the project.  Pretty smart.

No comments:

Post a Comment