summaryrefslogtreecommitdiff
path: root/modules/dev.module
diff options
context:
space:
mode:
Diffstat (limited to 'modules/dev.module')
-rw-r--r--modules/dev.module139
1 files changed, 139 insertions, 0 deletions
diff --git a/modules/dev.module b/modules/dev.module
new file mode 100644
index 000000000..b5c5773d0
--- /dev/null
+++ b/modules/dev.module
@@ -0,0 +1,139 @@
+<PRE>
+<H1>Drop.org - Development information</H1>
+<I><SMALL>$Id$</SMALL></I>
+
+
+ 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.
+
+ 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.
+
+<H2>CVS</H2>
+
+ <H3>Introduction</H3>
+
+ 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.
+
+ 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.
+
+ 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.
+
+ In addition, CVS helps to keep track of all changes. Therefore, I did
+ setup the CVS server to mail all CVS commits to droppies@drop.org.
+ 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.
+
+ By using a few trics I did setup the CVS to behave as follows: when
+ you check in a new or updated file, either from a work directory on
+ zind.net or from your local Windows/Linux machine, http://beta.drop.org/
+ is automatically updated! That is, http://beta.drop.org/ contains the
+ latest updates and patches. Whenever we have a stable build, we'll
+ export that stable build to http://www.drop.org/ after which we
+ continue working on http://beta.drop.org/.
+
+
+ <H3>Basic usage</H3>
+
+ <B>Linux</B>
+
+ 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.
+
+ 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.
+
+ 2. Set CVSROOT in your environment:
+ <I>export CVSROOT=":pserver:your_username@drop.org:/home/dries/cvs"</I>
+
+ 3. Login by running the command:
+ <I>cvs login</I>
+
+ 4. To check out the latest drop.org sources, run the command:
+ <I>cvs co drop</I>
+
+ 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.
+
+ 5. Whenever you want to merge in the latest code changes, use the
+ following command from within the <CODE>drop</DROP> directory:
+ <I>cvs ci file1 file2 file3</I>
+
+ 6. To add binary files like gifs you have to use:
+ <I>cvs add <B>-kb</B> file1 file2 file3</I>
+ If a binary file accidentically gets added without `-kb', one
+ can use the <I>cvs admin</I> command to recover. For example:
+ <I>cvs admin -kb file1 file2 file3</I>
+ <I>cvs commit file1 file2 file3</I>
+ After you did, make sure to check out a fresh copy of the files
+ (if they were broken):
+ <I>cvs update -A file1 file2 file3</I>
+
+
+ <B>Windows</B>
+
+ 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>.
+
+ 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>.
+
+
+ <H3>Additional references</H3>
+ 1. <A HREF="http://cvsbook.red-bean.com/">CVS book</A></LI>
+ 2. <A HREF="http://www.loria.fr/~molli/cvs/doc/cvs_toc.html">CVS docs</A></LI>
+ 3. <A HREF="http://cellworks.washington.edu/pub/docs/cvs/cvs-FAQ/">CVS FAQ</A></LI>
+
+
+<H2>diff and patch</H2>
+
+ 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.
+
+ patch is diff's complement and takes a patch file generated by diff
+ and applies it against a file or a group of files.
+
+ The actual usage of diff and patch is not complicated.
+
+ At its simplest, a diff command for comparing two files would be:
+ <I>diff old.txt new.txt > oldnew.patch</I>
+
+ For drop.org, we prefer patches in unified format, so we add -u to
+ the command line:
+ <I>diff -u old.txt new.txt > oldnew.patch</I>
+
+ Generally, however, a comparison of two source trees is often
+ desired. A possible command to do so is:
+ <I>diff -ruN old new > oldnew.patch</I>
+
+ Once a patch is generated, the process of patching the file is
+ even simpler. Based on our examples above, we could do:
+ <I>patch < oldnew.patch</I>
+
+</PRE>