CreatingPatches

Getting the DSLinux source tree

See this page.

Working with anonymous Subversion checkouts

How an anonymous Subversion checkout helps you

With an anonymous Subversion checkout, you cannot commit into the Subversion repository.

But you still have a couple of interesting commands available. You can view commit log messages, view differences between all revisions of any file and view the changes you have made to the tree yourself.

I really recommend reading this freely available book on Subversion: http://svnbook.red-bean.com. Knowing Subversion well will help you a lot in your life as a programmer. You will very likely not get commit access to any open source project using Subversion if you don't know how to use it well.

Useful Subversion commands

Here are some useful commands to get you going.

To view commit log messages of file.c, run:

 svn log file.c

To view the status of a file (up-to-date, locally modified, etc.), run:

 svn status file.c

To view changes you have made to file.c locally, run:

 svn diff file.c

This output of the diff command is a patch, so we will also use it to generate patches (see below).

To see what has changed in file.c between revisions 41 and 42, run:

 svn diff -r41:42 file.c

Read the Subversion book for more commands.

Good patches

What are good patches? In general, good patches allow committers to include your changes efficiently, without having to replicate a lot of the work you already have done.

Of course, committers do their best to test your submissions before committing them. So please consider the committer's situation while submitting your patch. Will the patch work out of the box when applied? Is there anything needed to test a program you are submitting that is outside the scope of the DSLinux source tree, such as a network server or special hardware? What needs to be done to test your submission? If you have non-obvious answers to these questions, please include them in your submission email.

Also, make sure that your patch only describes differences between the current state of the DSLinux source tree and your modifications! Patches are meant to be a readableform of a set of changes made to a source tree.

Note again, patches are supposed to be readable. If you cannot comfortably read your patch and tell what it is changing and why it is not a good patch. A patch that is almost as large as the source tree it's supposed to patch is useless.

Only files that you created to make the build work should appear in the patch in their entirety, e.g. a Makefile you've written from scratch. Nothing else.

If you are only adding new files, consider offering an archive for download (preferably in .tar.gz format, aka tarball) instead of sending a patch.

Try to keep your patch against upstream sources as small as possible. This means avoiding unnecessary changes, such as fixing whitespace (unless it is absolutely needed to fit the program in 64 columns). You can submit "unnecessary" patches upstream so DSLinux will import them with the next upstream release of the software.

If your patch contains both a lot of new files and modifications to existing files, consider providing the new files separately for download, and include only modifications to existing files in your patch.

Alas, if only a very small portion of your patch consits of new files, you may send everything in a single patch nonetheless. But be prepared that you may be asked to re-submit things differently, depending on the situation.

Patches that contain unneeded junk are hard to read and there is more work involved in making them apply correctly. So they will likely be rejected when you submit them.

Generating a patch to a single file

Say you have modified file.c in the DSLinux tree to fix some compiler warnings. Use the following command to create a patch against the file:

 svn diff file.c > ~/dslinux-file.c-fix-compiler-warnings.diff

Generating a patch to multiple files

Say you have modified multiple files of the program tool, living in a directory also called tool, to make it much better. Use the following command to create a patch for all your changes to all files inside the tool directory:

 svn diff tool/ > ~/dslinux-tool-much-better.diff

You can pass svn diff as many files and directories as you like. For example, to put all your changes to user/net-tools, vendor/Nintendo/common/rc.d/network and any files and directories below linux-2.6.x/driversinto a single patch, run:

 svn diff user/net-tools vendor/Nintendo/common/rc.d/network linux-2.6.x/drivers > ~/dslinux-mypatch.diff

Running

 svn diff > ~/dslinux-mypatch.diff

in the toplevel directory of the source tree will create a patch with allmodifications you have made to the source tree.

Dealing with new files and directories

Subversion only considers new files and directories that have been marked as added with the svn addcommand.

To add a directory called "mytool" to the user/ directory in the source tree, do the following:

 cd dslinux/user/ mkdir mytool svn add mytool

If mytool contains any files or subdirectories, they will be added automatically. Now they will show up in your diff, too.

Note that svn addonly adds files and directories to your local working copy of the repository, not the repository itself, since anonymous checkouts are read-only with respect to the repository.

Generating a patch for ported applications and libraries

See the porting howto.

Updating your tree while working on a patch

Just run

 svn update

Don't worry, svn will leave your local changes alone. If svn says something about conflicts during the update, read this sectionof the Subversion book.

Changing configuration files

You should update configuration files in vendors/Nintendoalong with your patch if needed. The following rules apply:

 Kernel/Library/Defaults Selection --> [*] Update Default Vendor Settings

* After using menuconfig to add your program to each vendor that should have it enabled, run buildbuild.sh -u