Will Andrews <will@physics.purdue.edu> writes:
> Other problems include the rather nasty ac-helper gnu-patch.sh,
> which fails on FreeBSD because it's not quite GNU patch, but
> supports many of the GNU patch extensions (but FreeBSD does ship
> with GNU diff 2.7). Since I don't know the precise details of
> what subversion requires from patch(1) and diff(1), I can't
> suggest a better approach to checking patch(1)/diff(1) to make
> sure they support subversion properly. But likely the approach
> would be to actually test some/most of the various features
> subversion relies on. I would appreciate if someone provided
> information on this.
I wrote gnu-patch.sh, and also am a FreeBSD user.
Subversion uses diff/patch behind the scenes when it receives an
update to a file. It uses them to "merge" the update into any local
mods that might exist. (Someday we hope to use an internal, librarized
version of diff/patch, the way CVS does.)
The problem is that the version of patch shipped by FreeBSD is a
slightly-hacked version of GNU patch. I forget why the FreeBSD team
decided to modify it -- but whatever the rationale, this version of
patch is unable to deal with files that do not end with a newline.
In other words, if I have a textfile that contains one line and does
*not* end with a newline, and I receive an update that adds one word
to the end of the line -- the FreeBSD version of GNU patch will choke
and claim the two files are unmergeable (and the file will be marked
as (C)onflict). The normal GNU patch does the merge just fine; it
add a special code to the patchfile to indicate lack of newline, I
believe.
That's the whole story. The "right" way to do things is to use an
internal diff/patch library. Until that day comes, we have to
standardize on the true-blue 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:41 2006