diff options
Diffstat (limited to 'modules/dev.module')
-rw-r--r-- | modules/dev.module | 139 |
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> |