I always use (in linux/unix)
patch -p0 < patchfile.diff
The -p0 means use the current path. For example, if the diff was created in trunk, then if you are trying to patch in trunk, then I always use -p0. If, for some reason, I was down one level in src, and the diff was from the trunk, then I would use: patch -p1 < patchfile.diff. That get's rid of the trunk path.
If your getting rejects, then you can look at the output of the rejects, and somewhat understand what is going on. Normally this is due to a difference in the svn revision number that the diff was used, and the current svn revision that the person is trying to apply the patch too. You can use a fuzz number to sometimes get a patch to get in, but it's better to get a new diff, or `svn up` the local revision. Sometimes this is a problem when lot's of people are making changes all at one time. (I have made a few people really upset by updating some code while they were working on it. They could have added their code by changes to the fuzz level....)
From the man patch:
"
PATCH(1) PATCH(1)
NAME
patch - apply a diff file to an originalSYNOPSIS
patch [options] [originalfile [patchfile]]but usually just
patch -pnum <patchfile
"
"
-F num or --fuzz=num
Set the maximum fuzz factor. This option only applies to diffs
that have context, and causes patch to ignore up to that many lines
in looking for places to install a hunk. Note that a larger fuzz
factor increases the odds of a faulty patch. The default fuzz fac-
tor is 2, and it may not be set to more than the number of lines of
context in the context diff, ordinarily 3.
"
"
-pnum or --strip=num
Strip the smallest prefix containing num leading slashes from each
file name found in the patch file. A sequence of one or more adja-
cent slashes is counted as a single slash. This controls how file
names found in the patch file are treated, in case you keep your
files in a different directory than the person who sent out the
patch. For example, supposing the file name in the patch file was
/u/howard/src/blurfl/blurfl.c
setting -p0 gives the entire file name unmodified, -p1 gives
u/howard/src/blurfl/blurfl.c
without the leading slash, -p4 gives
blurfl/blurfl.c
and not specifying -p at all just gives you blurfl.c. Whatever you
end up with is looked for either in the current directory, or the
directory specified by the -d option.
"
scott
Jeff Levitt wrote:
I just created a new patch, and it seems that the "src/" was left off the file names in the first patch. Maybe that has something to do with it? I created the attached diff from the trunk. Its also a more current revision number.
Does it work?
--- "Jean T. Anderson" <[EMAIL PROTECTED]> wrote:
I'm having trouble applying this patch, but perhaps
I'm not getting the patch syntax correct. I've succeeded previously
applying Jeff's patches that modified just one file, and this is the first
time I have tried to apply a patch that modifies more than one file.
So, it modifies three files relative to the current working directory:
[EMAIL PROTECTED] ref]$ grep "^Index:" resultsets_changes.diff Index: rrefjdbc77156.dita Index: rrefcorrelationname.dita Index: rrefcolumnname.dita
So I put the patch in trunk/src/ref , then tried to
apply it but there are a couple failures:
[EMAIL PROTECTED] ref]$ patch -i resultsets_changes.diff patching file rrefjdbc77156.dita Hunk #4 FAILED at 166. 1 out of 4 hunks FAILED -- saving rejects to file rrefjdbc77156.dita.rej patching file rrefcorrelationname.dita Hunk #1 FAILED at 19. 1 out of 1 hunk FAILED -- saving rejects to file
rrefcorrelationname.dita.rej patching file rrefcolumnname.dita
what's the right way to debug this? I attached the two reject files.
By the way, I tried to apply this with the DITA
source at revision 168249. Jeff, what was the revision of your local
copy when you produced the patch? --There is a backlog of patches to apply
in Jira (and which I'll try to catch up on). I'm wondering if it's
possible this patch depends on one of those and I'm applying it out of
order.
thanks,
-jean
