db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From scott hutinger <...@www.mprojects.Horrabin.wiu.edu>
Subject Re: [patch] [doc] updatable ResultSets [having trouble applying patch]
Date Thu, 05 May 2005 05:31:58 GMT
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 - apply a diff file to an original

       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  
          that have context, and causes patch to ignore up to that many 
          in looking for places to install a hunk.  Note that a  larger  
          factor increases the odds of a faulty patch.  The default fuzz 
          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 
          file name found in the patch file.  A sequence of one or more 
          cent  slashes is counted as a single slash.  This controls how 
          names found in the patch file are treated, in case  you  keep  
          files  in  a  different  directory than the person who sent 
out the
          patch.  For example, supposing the file name in the patch file was


          setting -p0 gives the entire file name unmodified, -p1 gives


          without the leading slash, -p4 gives


          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.



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" <jta@bristowhill.com> 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:
>>    [jta@gertie3 ref]$ grep "^Index:"
>>    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:
>>    [jta@gertie3 ref]$ patch -i
>>    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
>>    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
>>  -jean

View raw message