'patch' behaviors

OK, I've done my deductive detective work, and I now know why so many
of our python tests are failing on FreeBSD, and not on Linux.

As I suspected, it's the 'patch' program. The 'patch' executable on
FreeBSD is the original Larry Wall program, version 2.1. The 'patch'
executable on GNU/Linux systems is FSF's own extended branch, version
2.5.

The problem revolves around a bug in the older version.

Define a "one line file" to mean a file with one line of text, which
does *not* end with a newline. If I have a patchfile that converts a
one-line file into a different one-line file, the GNU patch program
handles it correctly, while the older patch program actually *adds* an
extra \n to the file.

Here's a script which you can run on BSD and Linux to demonstrate the
bug:

----------------------------
#!/bin/sh

# create two identical one-line files.
echo -n "some text, no newline" > foofile
cp foofile foofile2

# append to the first one
echo -n "...extra text, still no newline" >> foofile

# do a diff
diff -u foofile foofile2 > foo.patch

# apply the patch to foofile
patch < foo.patch

# the files should be *identical* now. examine hexdumps:
hexdump foofile
hexdump foofile2
----------------------------

On Linux, the hexdump printouts are identical. On FreeBSD, the
patched file has an extra newline.

So, on FreeBSD, when we run the python tests to update a working copy,
we expect to see a 'U' printed when a file is updated. Instead we see
a 'G', which makes the test fail. The 'G' is printed because the
update trace-editor notices that the patched working file and the
text-base copy have differing numbers of bytes -- and therefore
assumes that the working file must have had local mods!

So... what to do? Python tests 7, 8, 9 are all failing due to
different side-effects of this patch bug. Is the best solution just
to have autoconf look for (and require) GNU patch?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:32 2006