[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] XaAES:update:CONFIGVARS
Vincent Rivière wrote:
Just as a precision: you can use diff on directories to make a single
patch for all the files. Typycally, before working on the MiNTLib, I
make a reference copy named mintlib.orig and I keep it clean. Then I
work in the "mintlib" original directory. At the end, I do:
make clean
diff -Naur mintlib.orig mintlib >mypatch.patch
Since we are speaking about patch files, I take the occasion to give some
precisions of how I work on Windows. It is not the best practices, but my
own practices for cross-development, so any improvement is welcome.
There is an interest of keeping the original files in a "orig" directory. I
can use any tool for comparing them. When comparing to the remote CVS
repository, I could only use diff (tell me if I'm wrong).
So, when I'm done with the work I targeted inside the "mintlib" directory, I
usually use 2 tools to compare the directories.
- Windiff, a small tool provided with Microsoft's Platform SDK. He provides
a flat view of the list of modified files. By clicking on a file, it opens
an unified and colorized read-only view of the full file, with removed lines
in red and added lines in yellow. It is a very basic tool but it is very
handy (but read only).
- Winmerge, a well-known open source project.
http://winmerge.org/
It displays the list of modified files in a tree, so this view is not very
comfortable. But when editing a file, it displays the 2 versions on 2
columns. The changes are highlighted (even inside lines), and they can be
undone with a single keystroke. So if I have inadvertently added a blank
line, or removed the blanks at the end of a line that finally does not
require any change, I can revert it very easily.
Then, when the only changes remaining are the useful ones regarding to my
changelog objective, I generate the patch with the "diff -Naur" command. I
make a final check of the patch file visually by opening it with Notepad++,
because it appears colorized and very readable.
Of course the patch must contain all the files modified for the targeted
changelog (sources, makefiles, scripts...), and keep the repository in a
compilable and working state !
Another thing about "unified diffs" (the u option). They are very powerful
and secure, that's why it is well suited for making patch files that can be
applied automatically.
If a new file is added, "diff" sees it, and "patch" will create it.
If a file is deleted, "diff" sees it too, and "patch" will delete it.
For modified files, "diff" include the modified lines, with 3 lines of
context just before and after (in addition to line numbers). So "patch" can
check on the target if it is really at the good place. If some lines have
been added by someone else at the top of the file, "patch" will be able to
find the lines to be modified, and thanks to the context lines, in practice
it always does the right thing.
However, if someone has modified the exact same lines as in the patch, the
automatic patching process will fail, and of course a programmer has to
choose what to do. But in practice, it happens rarely, because in a single
source file there are actually very few modifications.
So the "patch" tool is very robust, it is used in nearly all the
open-sources projects, and the "unified diff" is the de facto format for
providing code changes on mailing lists. As we said many times, it allows
other developers to see quickly what has been changed, and to alert the
maintainers if something is wrong.
If I downloaded a patch to my home directory, I can apply to a source tree
like this:
$ cd mintlib
$ cat ~/thepatch.patch |patch -p1
This will add/remove/change automatically all the files specified in the
patch file. Note the p1 option. This is because I created the patch from
outside the mintlib directory (by diffing 2 directories), but I apply it
inside the mintlib directory. So 1 level of directories have to be stripped
from the filenames specified in the patch file, that's the purpose of the
-p1 option.
And I will give an another advice. When posting a patch to the list, it is
best to use the MIME type "text/plain" for the attached file (for example,
Thunderbird does this automatically). This has a number of advantages:
- some mail clients (like Thunderbird) can display the patch "inline", so
the patch contents appears after the message without having to open it.
- the patch is readable in the mailing list archives on the web (it is not
the case for files encoded with base64).
- the patch contents in the mailing list archives can be indexed by search
engines.
As an example, here is a patch I provided on the list some time ago. I
believe it is not so bad because Frank committed it without complaining.
http://sparemint.org/mailinglist/Mailing-Lists/MiNT-List.200905/4A1FDD91.9060709@freesbee.fr.text
I'm not here to give lessons, I have just shown how I usually provide
changes to open source projects, and they always have been accepted.
There are very few developers on MiNT software, every contribution is very
precious. So let's do things the right way, it will be a benefit for everyone.
--
Vincent Rivière