Drupal
/
drupal
mirror of https://git.drupalcode.org/project/drupal.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

- developement.module is now integrated into documentation.module 

(keeps the code base smaller)
3-00
Dries Buytaert 2000-12-30 11:59:16 +00:00
parent 44c4800434
commit c9c6c21620
1 changed files with 0 additions and 116 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

116
modules/development.module
View File

@ -1,116 +0,0 @@
<?
$module = array("page" => "development_page");
function development_page() {
?>
<H1>Development</H1>
<I><SMALL>$Id$</SMALL></I>
<P>drop.org is open source. It is possible for each and every user to become a contributor. The fact is that most drop.org users, even those skilled in programming arts, have never contributed to the code even though most of us had days where we thought to ourselves: "I wish drop.org could do this ...". Through this page, I hope I can make drop.org programming more accessible to at least a small percentage of people.</P>
<P>We use diff and patch for content control even though we distribute our code via CVS. Why? Because diff and patch provide an immense amount of control. Patches can be submitted via e-mail and in plain text; maintainers can read and judge the patch before it ever gets near a tree. It allows maintainers to look at changes easily without blindly integrating them.</P>
<H2>Chapter 1: CVS</H2>
<H3>Introduction</H3>
<P>CVS is a tool to manage software revisions and release control in a multi-developer, multi-directory, multi-group environment. It comes in very handy to maintain local modificiations.</P>
<P>Thus, CVS helps you if you are part of a group of people working on the same project. In large software development projects, it's usually necessary for more then one software developer to be modifying modules of the code at the same time. Without CVS, it is all too easy to overwrite each others' changes unless you are extremely careful.</P>
<P>We can hand out CVS accounts rather then full-features shell accounts or ftp accounts, and having to mess with groups to give everyone access to the sources. We could create a public read-only CVS account so beta testers could checkout the latest snapshot of the code.</P>
<P>In addition, CVS helps to keep track of all changes. Therefore, the CVS server has been setup to mail all CVS commits to all maintainers. Thus, it does not require any effort to inform the other people about the work you have done, and by reading the mails everyone is kept up to date.</P>
<H3>Basic usage</H3>
<B>Linux</B>
<P>To gain access via (anonymous) cvs use the following steps. For this example it is assumed that you want a copy of the drop.org source code.</P>
<P>1. Install a recent copy of cvs. All you really need is a copy of the CVS client binary. Or you can download the latest CVS source code from <A HREF="http://www.cyclic.com">Cyclic Software</A>. Don't get your panties in a nod; CVS is free software under the GNU GPL.</P>
<P>2. Set CVSROOT in your environment:</P>
<BLOCKQUOTE>export CVSROOT=":pserver:your_username@drop.org:/home/dries/cvs"</BLOCKQUOTE>
<P>3. Login by running the command:</P>
<BLOCKQUOTE>cvs login</BLOCKQUOTE>
<P>4. To check out the latest drop.org sources, run the command:</P>
<BLOCKQUOTE>cvs co drop</BLOCKQUOTE>
<P>This will create a directory called <CODE>drop</CODE> containing the latest drop.org source tree. For the other source code repositories on this system just substitute the correct package name.</P>
<P>5. Whenever you want to merge in the latest code changes, use the following command from within the <CODE>drop</CODE> directory:</P>
<BLOCKQUOTE>cvs ci file1 file2 file3</BLOCKQUOTE>
<P>6. To add binary files like gifs you have to use:</P>
<BLOCKQUOTE>cvs add <B>-kb</B> file1 file2 file3</BLOCKQUOTE>
<P>If a binary file accidentically gets added without `-kb', one can use the <I>cvs admin</I> command to recover. For example:</P>
<BLOCKQUOTE>cvs admin -kb file1 file2 file3<BR>cvs commit file1 file2 file3</BLOCKQUOTE>
<P>After you did, make sure to check out a fresh copy of the files (if they were broken):</P>
<BLOCKQUOTE>cvs update -A file1 file2 file3</BLOCKQUOTE>
<B>Windows</B>
<P>A graphical CVS client is available for MS Windows and for Macs. You can download the latest version from <A HREF="http://www.wincvs.org">http://www.wincvs.org/</A>.</P>
<P>If you can want to interface the CVS repository just like Linux users do (raw and uncut), then check <A HREF="http://oodt.jpl.nasa.gov/doc/developers-resources/developing/windows/index.html">this site</A>.</P>
<H3>Additional references</H3>
<UL>
<LI><A HREF="http://cvsbook.red-bean.com/">CVS book</A></LI>
<LI><A HREF="http://www.loria.fr/~molli/cvs/doc/cvs_toc.html">CVS docs</A></LI>
<LI><A HREF="http://cellworks.washington.edu/pub/docs/cvs/cvs-FAQ/">CVS FAQ</A></LI>
</UL>
<H2>Chapter 2: diff and patch</H2>
<P>Diff is the first command in the set. It has the simple purpose to create a file called a <I>patch</I> or a <I>diff</I> which contains the differences between two text files or two groups of text files. diff can write into different formats, although the unified difference format is preferred. The patches this command generates are much easier to distribute and allow maintainers to see quickly and easily what changed and to make a judgement.</P>
<P>Patch is diff's complement and takes a patch file generated by diff and applies it against a file or a group of files.</P>
<P>The actual usage of diff and patch is not complicated.</P>
<P>At its simplest, a diff command for comparing two files would be:</P>
<BLOCKQUOTE>diff old.txt new.txt > oldnew.patch</BLOCKQUOTE>
<P>For drop.org, we prefer patches in unified format, so we add -u to the command line:</P>
<BLOCKQUOTE>diff -u old.txt new.txt > oldnew.patch</BLOCKQUOTE>
<P>Generally, however, a comparison of two source trees is often desired. A possible command to do so is:</P>
<BLOCKQUOTE>diff -ruN old new > oldnew.patch</BLOCKQUOTE>
<P>Once a patch is generated, the process of patching the file is even simpler. Based on our examples above, we could do:</P>
<BLOCKQUOTE>patch < oldnew.patch</BLOCKQUOTE>
<H2>Chapter 3: creating and sending your patches</H2>
<P>For a person or company who wishes to submit a change, the process can sometimes be daunting if you're not familiar with "the system". This text is a collection of suggestions which can greatly increase the chances of your change being accepted.</P>
<P>1. <B>Coding style:</B><BR>If your code deviates too much from the "standard" coding style, it is more likely to be rejected without further review and without comment.</P>
<P>2. <B>"diff -u":</B><BR>Use "diff -u" or "diff -urN" to create patches: when creating your patch, make sure to create it in "unified diff" format, as supplied by the '-u' argument to diff. Patches should be based in the root source directory, not in any lower subdirectory. Make sure to create patches against a "vanilla", or unmodified source tree.</P>
<P>3. <B>Describe your changes:</B><BR>Describe the technical detail of the change(s) your patch includes and try to be as specific as possible. Note that we prefer technical reasoning above marketing: give us clear reasons why "this way" is good. Justify your changes and try to cary enough weigth. It is important to note the version to which this patch applies.</P>
<P>4. <B>Separate your changes:</B><BR>Separate each logical change into its own patch. For example, if your changes include both bug fixes and performance enhancements, separate those changes into two or more patches. If your changes include an API update, and a new module which uses that new API, separate those into two patches.</P>
<P>5. <B>Mail or submit the patch:</B><BR>Remember: no MIME, no HTML mail, no links, no compression, no attachments. Just plain text.</P>
<?
}
?>