mozilla

Compare Revisions

Creating a patch

Change Revisions

Revision 37807:

Revision 37807 by Kray2 on

Revision 37808:

Revision 37808 by chinmay on

Title:
Creating a patch
Creating a patch
Slug:
Creating_a_patch
Creating_a_patch
Tags:
NeedsTechnicalReview, "Developing Mozilla"
NeedsTechnicalReview, "Developing Mozilla"
Content:

Revision 37807
Revision 37808
nn8       
9    </p>
10    <p>
8      After you have <a href="en/Mozilla_Source_Code_Via_CVS">obt11      After you have <a href="/en/Mozilla_Source_Code_(CVS)" titl
>ained the source code</a>, made changes to it, <a href="en/Build_>e="en/Mozilla_Source_Code_(CVS)">obtained the source code</a>, ma
>and_Install">built</a> and <a href="en/Mozilla_automated_testing">de changes to it, <a href="/en/Build_and_Install" title="en/Build
>>tested</a> it (and included your tests in your patch, if possibl>_and_Install">built</a> and <a href="/en/Mozilla_automated_testin
>e), you'll want to get your changes <a href="en/Getting_your_patc>g" title="en/Mozilla_automated_testing">tested</a> it (and includ
>h_in_the_tree">reviewed and checked in</a>. In order to do that, >ed your tests in your patch, if possible), you'll want to get you
>you need to create a file listing the changes you made, called a >r changes <a href="/en/Getting_your_patch_in_the_tree" title="en/
><i>patch</i> or a <i>diff file</i>. You can generate it using <b>>Getting_your_patch_in_the_tree">reviewed and checked in</a>. In o
>cvs diff</b> or <b>hg diff</b> command.>rder to do that, you need to create a file listing the changes yo
 >u made, called a <em>patch</em> or a <em>diff file</em>. You can 
 >generate it using <strong>cvs diff</strong> or <strong>hg diff</s
 >trong> command.
n12        This article is written about CVS; for Mozilla 2 (ie evern15        This article is written about CVS; for Mozilla 2 (ie ever
>thing after 1.9.0), we switched to another source control system >thing after 1.9.0), we switched to another source control system 
>- <a href="en/Mercurial">Mercurial</a>. While the ideas are the s>- <a href="/en/Mercurial" title="en/Mercurial">Mercurial</a>. Whi
>ame, the specific commands and tips may not apply anymore. See <a>le the ideas are the same, the specific commands and tips may not
> href="en/Mercurial_FAQ#How_can_I_diff_and_patch_files.3F">Mercur> apply anymore. See <a href="/en/Mercurial_FAQ#How_can_I_diff_and
>ial FAQ#How can I diff and patch files?</a> for the complete list>_patch_files.3F" title="en/Mercurial_FAQ#How_can_I_diff_and_patch
> of hg commands and tips.>_files.3F">Mercurial FAQ#How can I diff and patch files?</a> for 
 >the complete list of hg commands and tips.
n19      People who need to apply your patch will be grateful if youn22      People who need to apply your patch will be grateful if you
> generate it by running <tt>cvs diff</tt> from the top-level <tt>> generate it by running <code>cvs diff</code> from the top-level 
>mozilla/</tt> directory. (In this case they can apply it by runni><code>mozilla/</code> directory. (In this case they can apply it 
>ng <tt>patch -p0 &lt; <i>your_patch</i></tt> from the top-level d>by running <code>patch -p0 &lt; <em>your_patch</em></code> from t
>irectory without looking at the patch.)>he top-level directory without looking at the patch.)
n34      This creates a diff in the so called 'unified' format (<tt>n37      This creates a diff in the so called 'unified' format (<cod
>-u</tt>), with 8 lines of context. The diff is printed to stdout >e>-u</code>), with 8 lines of context. The diff is printed to std
>by default. To redirect the output to a file, use something like:>out by default. To redirect the output to a file, use something l
 >ike:
n64      To include a new file in your patch, use the <tt>-N</tt> opn67      To include a new file in your patch, use the <code>-N</code
>tion:>> option:
n70      A common problem here is that <b>cvs diff</b> will not incln73      A common problem here is that <strong>cvs diff</strong> wil
>ude the new files that were not <b>cvs add</b>ed, and cvs add req>l not include the new files that were not <strong>cvs add</strong
>uires write access to repository.>>ed, and cvs add requires write access to repository.
n73      The solution is to use the <a class="external" href="http:/n76      The solution is to use the <a class="external" href="http:/
>/viper.haque.net/~timeless/redbean/"><b>cvsdo</b> utility</a>, wh>/viper.haque.net/~timeless/redbean/"><strong>cvsdo</strong> utili
>ich edits <tt>CVS/Entries</tt> to make cvs think the file is adde>ty</a>, which edits <code>CVS/Entries</code> to make cvs think th
>d to repository:>e file is added to repository:
n103      When generating a patch you can ask <tt>diff</tt> to ignoren106      When generating a patch you can ask <code>diff</code> to ig
> whitespace changes. This is especially useful if you are doing a>nore whitespace changes. This is especially useful if you are doi
> lot of indentation changes, such as when wrapping or unwrapping >ng a lot of indentation changes, such as when wrapping or unwrapp
>parts of the code inside <code>if</code> statements. To create a >ing parts of the code inside <code>if</code> statements. To creat
>patch without whitespace changes use the <tt>-w</tt> flag. So if >e a patch without whitespace changes use the <code>-w</code> flag
>you use:>. So if you use:
n115      When doing so, please make sure that <b>both</b> patches arn118      When doing so, please make sure that <strong>both</strong> 
>e attached to the bug (the patch without <tt>-w</tt> is needed fo>patches are attached to the bug (the patch without <code>-w</code
>r the reviewer to check that whitespace changes are done correctl>> is needed for the reviewer to check that whitespace changes are
>y and for the person doing the check-in for you to apply your cha> done correctly and for the person doing the check-in for you to 
>nges).>apply your changes).
n121      There are some tools available that may help to catch some n124      There are some tools available that may help to catch some 
>errors within your patch thus making your and your reviewer's job>errors within your patch thus making your and your reviewer's job
> a little easier, here are some that may be useful: <a class="ext> a little easier, here are some that may be useful: <a class="ext
>ernal" href="http://www.johnkeiser.com/cgi-bin/jst-review-cgi.pl">ernal" href="http://beaufour.dk/jst-review/" title="http://beaufo
>>JST Review Simulacrum</a>.>ur.dk/jst-review/">JST Review Simulacrum</a>.
t127      <a href="en/Getting_your_patch_in_the_tree">Getting your pat130      <a href="/en/Getting_your_patch_in_the_tree" title="en/Gett
>tch in the tree</a>>ing_your_patch_in_the_tree">Getting your patch in the tree</a>
131    </p>
132    <p>
128    </p>{{ languages( { "fr": "fr/Cr\u00e9ation_d\'un_patch", "it133      {{ languages( { "fr": "fr/Cr\u00e9ation_d\'un_patch", "it":
>": "it/Creare_patch", "ja": "ja/Creating_a_patch" } ) }}> "it/Creare_patch", "ja": "ja/Creating_a_patch" } ) }}
134    </p>

Back to History