1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
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>
|
