On Dec 20, 9:57, Martin Buchholz wrote:
I tried to apply Daniel Pittman's patch created by `cvs diff'
workspace using `patch -d /my/workspace'. However, it only patched
the files in the root directory, like configure.in. Files in the
lwlib/ directory couldn't be found by patch, even though the headers
for those files look like:
RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/Attic/xlwradio.h,v
retrieving revision 18.104.22.168
diff -u -r22.214.171.124 xlwradio.h
--- xlwradio.h 1999/07/30 09:13:56 126.96.36.199
+++ xlwradio.h 1999/12/16 09:34:00
The documentation for `patch' indicates that it should look at the
Index: line when patching. So why couldn't it find the file to
patch? More generally, what is the procedure for applying patches
generated by `cvs diff'?
I always add -pN to patch, otherwise it will *always* patch all files
in the top directory. Try adding -p0.
I haven't used patch 2.5 much, but in older versions 'patch' would
understand the Index line, but only to a limited extent: If there
was a file in the top directory then it would patch that one instead..
only if the file was unique would it patch it where it should be patched.
Gave me a lot of problems with ChangeLog and Makefile :-)
Patch was thus never very good with Index files anyway, so CVS was
fixed instead. More below.
Why doesn't cvs generate headers that look like this instead?
--- lwlib/xlwradio.h 1999/07/30 09:13:56 188.8.131.52
+++ lwlib/xlwradio.h 1999/12/16 09:34:00
The newer versions of CVS *do* generate these diffs. I just tried to
generate a diff from the xemacs CVS repository, it generated the old
diff so it looks like what matters is which version the server is using
(all diffs I generate from my own repositories are good).
I don't remember when this was fixed in CVS but I recommend upgrading
the server to something like 1.10.7 at least.
p.s. Somebody wrote a script to fix those old cvs diffs and posted it on
info-cvs. If it's out of the question upgrading CVS then I could try
to dig it out.