Generating the patch

A patch consists of the output of the diff program and should contain not only the changes made to any existing files, but also any new files that have been added. Patches should be relative to the current eCos CVS repository.

Here we present two alternative approaches for generating the patch against the CVS repository. Choose whichever you feel most comfortable with.

Approach 1

First, check out or update your CVS repository sources, and make your changes.

We will generate the set of differences - a patch, also known as a diff in two stages. First we will generate the changes for existing files. Then we will include any new files.

To generate the changes for existing files, this should simply be a case of using the following commands:

$ cd ecos/packages
$ cvs -q diff -u5 -p <changed files or directory containing files> >> <patch file>

For example:

$ cd ecos/packages
$ cvs -q diff -u5 -p devs/eth/arm/ebsa285 kernel hal/common/current/ChangeLog \
    hal/common/current/src/hal_if.c >> my.patch

For convenience, you can add the diff arguments to your ~/.cvsrc like so:

$ cat >> ~/.cvsrc
diff -u5 -p
<Ctrl-Z (windows) or Ctrl-D (unix)>
$

With this ~/.cvsrc in place you may then omit the -u5 -p arguments to the cvs diff command.

If you have created any new files, you must append them to the patch as follows in one of two ways:

1. With the following command at the same level as your earlier cvs diff:

   $ diff -u5N --from-file /dev/null <new files> >> <patch file>
   

   For example:

   $ diff -u5N --from-file /dev/null devs/flash/arm/wizzo/current/ChangeLog \
       devs/flash/arm/wizzo/current/cdl/wizzo.cdl \
       devs/flash/arm/wizzo/current/include/flash_wizzo.h >> my.patch
   

2. A more programmatical alternative is:

   $ cvs -q up <files or directories> | awk '/^\?/ {print $2}' | xargs -rn1 diff -u5rN /x >> <patch file>
   

   which will look at the files or directories to see what files are new and generate diffs for only them. This command assumes that a file or directory named /x does not exist.

Approach 2

First, make sure you have two copies of the current CVS repository. You can do this by either checking it out twice, or by copying an existing repository with the following command:

$ cp -a clean devo

We will call these two copies clean, which will be an unchanged copy of the CVS repository, and devo, which is where you will do your patch development work.

Now you can work on your patch in the devo repository. When it is complete, make sure it is tested and update the ChangeLog files or, if you are adding a new package, create new ChangeLog files. If it has been some time since you checked out the repository, do a cvs update in both repositories before continuing. Any new files you have added to the devo repository will be listed with a "?", this is normal and simply indicates that they are not currently checked in. Any files listed with a "C" indicate conflicts between your changes and any new changes in the repository. You must resolve these before continuing.

To generate the patch, execute the following command:

$ diff -r -u5 -N -x CVS -x "*~" -x ".#*" clean/ecos/packages devo/ecos/packages >my.patch

The "-r" option causes the diff to operate recursively; the "-u5" option generates unified diffs with a five line context, which are easier to read than other diff formats; the "-N" option causes all new files to be included in the diff; the "-x CVS" causes all CVS directories to be excluded and the "-x "*~" -x ".#*"" causes any editor backup files to be excluded -- these are for emacs, you may need to change them if you use a different editor. The clean repository should come first on the command line and the devo second. In this example we are only diffing the packages directories, if you have made changes to the host tools or the generic documentation, leave off the "packages" component from both paths. If the patch only applies to a single package then you can add directories to these paths to diff only that package. The final part redirects the output of the diff command into the file "my.patch". You should choose a more descriptive filename, although the ".patch" extension may be kept since it is recognised by various tools.