-
Notifications
You must be signed in to change notification settings - Fork 2
/
CVStips.html
406 lines (305 loc) · 9.94 KB
/
CVStips.html
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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=iso-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E" alink="#FF0000">
<h1>CVS Techniques</h1>
<i>This information is for historical reference only; the R source repository is now
maintained using Subversion. Please see <a href="SVNtips.html">Subversion tips</a>
instead.</i>
<h3>Preliminaries</h3>
<p> There are two main development branches for R. For reference, we call
<tt>r-devel</tt>, and
<tt>r-patched</tt>.
<p>After the release of R-x.y.z the two versions
work towards
<pre><kbd>
Version Name Tag
-----------------------------------------
R-x.(y+1).0 r-devel [none]
R-x.y.(z+1) r-patched R-x-y-patches
</kbd></pre>
The "Tag" column refers to CVS branch tags. The logic is that patch
releases (R-x.y.z, z!=0) are made from the branch tagged
"R-x-y-patches", whereas normal releases (R-x.y.0) are made from the
from the "trunk" i.e. the untagged files.
<p> In what follows, I use the reference names also as directory
names. All developers are encouraged to use the same names, to provide
us with a common reference.
<h3>Checking out a development branch</h3>
<p> (By a development branch, I mean either the trunk or a version
marked by a CVS branch tag)
<p> First set the CVSROOT environment variable and make sure it is
exported:<br>
For <tt>sh </tt>variants, use
<p>
<tt>CVSROOT=cvs.r-project.org:/home/rdevel/CVS-ARCHIVE</tt><br>
<tt>export CVSROOT</tt><p>
For <tt>csh </tt>and derivatives, use
<p>
<tt>setenv CVSROOT cvs.r-project.org:/home/rdevel/CVS-ARCHIVE</tt>
<p> If your username on <tt>franz</tt> aka <tt>cvs.r-project.org</tt> is
not
the same as your local user name you need to add it to CVSROOT, eg
<tt>setenv CVSROOT [email protected]:/home/rdevel/CVS-ARCHIVE</tt>
<p>
Also make sure that you have <tt>CVS_RSH </tt>set to ssh. I shall
assume the <tt>bash</tt> shell in the following, for simplicity, and
create the three development directories under $RTOP.
<pre><kbd>
export RTOP=~/R-devel #adjust as necessary
</kbd></pre>
<h4>The head revision</h4>
(aka "r-devel")
<pre><kbd>
mkdir -p $RTOP/r-devel
cd $RTOP/r-devel
cvs co -P R
</kbd></pre>
<p>
The <tt>-P</tt> option prunes empty directories. The checked out
directory will be called "R". Use the <tt>-d</tt> option to call it
something else.
<h4> Current patch branch</h4>
(aka "r-patched")
<pre><kbd>
mkdir -p $RTOP/r-patched
cd $RTOP/r-patched
cvs co -P -r R-1-9-patches R
</kbd></pre>
<h3>Checking out a specific release version</h3>
Release versions are labeled with a tag of the form R-1-2-3. (For
obscure reasons, non-patch versions up to R-1.3.0 were labeled R-1-3
and not R-1-3-0. This was changed starting with R-1.4.0.). You can
check out an old version simply with
<p>
<tt>cvs co -P -r R-1-2-3 R</tt>
<p>Notice however, that these tags are not branch tags, you cannot change
a released version and commit the changes back.
<h3>Updating</h3>
To update a source tree with the latest changes, just go to the
relevant top-level directory (e.g. $RTOP/r-patches/R) and say
<p>
<tt>cvs up -Pd</tt>
<p>If you want to make completely sure that the files come from a
given branch, add (say) <tt> -r R-1-9-patches </tt>. I am unsure
whether (and when) this is actually needed; there seems have been a
case where a new directory got added from the wrong branch.
<p>If you are on a slow connection, it generally works to take one
revision and convert it to another tagged revision by using e.g.
<p>
<tt>cvs up -Pd -r R-1-9-patches</tt>
<p>To create the trunk revision from a branch revision, use
<p>
<tt>cvs up -PdA</tt>
<p> Notice, however, that CVS is capable of getting things wrong,
notably if interrupted in the middle of an update. This can lead to an
infinite loop condition when updating. If that happens, I know no
remedy other that doing a fresh checkout instead.
<h3>Committing</h3>
To put your modified versions back in the repository, just say
<tt>cvs commit -m'describe change' FILE1 FILE2 ...</tt>
<p>or just
<p>
<tt>cvs commit</tt>
<p>in which case you'll be asked for a change comment.
<p>Notice that commits only works on the trunk and on branch
revisions. Non-branch tags represent the status of the files at a
given instance in the past which is unchangeable by definition.
<h3> Updating from r-patched to r-devel, entire tree</h3>
<pre><kbd>
# assumes that "last-patch-update" is set correctly
export RTOP=~/R-devel #adjust as necessary
export TAG=R-1-9-patches
cd $RTOP/r-devel/R
cvs rtag -F -r $TAG patch-update R
cvs update -Pd
cvs update -Pd -j last-patch-update -j patch-update
find -type f | xargs grep '>>>>>>>'
# fix conflicts...
cvs commit -m 'branch update'
# better do this right away...
cvs rtag -F -r patch-update last-patch-update R
</kbd></pre>
<h3> Updating from r-patched to r-devel, specific files</h3>
<pre><kbd>
FILES="src/main/unique.c NEWS" #change to your liking
PATCH=~/R-devel/r-patched/R #ditto
DEVEL=~/R-devel/r-devel/R #ditto
# fix and commit to r-patched as usual, e.g.
cd $PATCH
cvs up
vi $FILES
#----------
# TEST your CHANGES
#---------
cvs commit $FILES
# Note: Use cvs tag (not rtag) just in case someone commited a change
# in the meantime
cvs tag -F patch-update $FILES
cd $DEVEL
cvs update -j last-patch-update -j patch-update $FILES
grep '>>>>>>>' $FILES
#------------
# FIX CONFLICTS (if any)
# This technique is often helpful, although you need to be aware that
# ediff occasionally makes conflicts more complicated rather than
# less...
#
# emacs <filename> -f vc-resolve-conflicts
#------------
cvs commit -m 'branch update' $FILES
cvs tag -F -r patch-update last-patch-update $FILES
</kbd></pre>
<h2> Making releases </h2>
<h3> Dot-release (x.y.0) </h3>
<pre><kbd>
MAJOR=1
MINOR=9
PL=0
NEWMAJOR=2
NEWMINOR=0
TAG=R-$MAJOR-$MINOR-$PL
BRANCHTAG=R-$MAJOR-$MINOR-patches
REL=R-$MAJOR.$MINOR.0
OREL=R-1.8.1
echo -e "TAG=$TAG\nREL=$REL\nOREL=$OREL"
export CVSROOT=/home/rdevel/CVS-ARCHIVE
cd ~/r-devel
rm -rf R BUILD
cvs checkout -P R
#-- set/check version number and release status:
cd R
tools/rsync-recommended
echo $MAJOR.$MINOR.$PL > VERSION
autoconf
mkdir ../BUILD
cd ../BUILD
# FIXME: this'll build against Tcl 8.0 on Franz and so might
# break future versions
../R/configure --enable-maintainer-mode --prefix ~/$REL
make && make check && make check-devel && make check-all
cd ~/r-devel/R
cvs update -Pd # watch out for merges!
cvs commit -m 'preparing for release'
#---- at specified time:
cd ~/r-devel/R
cvs update -Pd # watch out for last minute merges -
# make check again if necessary!
cvs rtag $TAG R
cvs rtag -b -r $TAG $BRANCHTAG R
cd ~
rm -rf r-patched
mkdir r-patched
cd r-patched
cvs checkout -P -r $BRANCHTAG R
cd ~/r-devel/BUILD
make dist
cp $REL.tar.gz $FTPDIR/$REL.tgz
cd ../R
cp README INSTALL RESOURCES NEWS Y2K $FTPDIR
cd $FTPDIR
split -b 1400k $REL.tgz $REL.tgz-split.
ln -sf $REL.tgz R-latest.tgz
# -- set release numbers on release and devel. versions
cd ~/r-devel/R
echo $NEWMAJOR.$NEWMINOR.0 "Under development (unstable)" > VERSION
cvs commit -m 'prepare for next version' VERSION
cd ~/r-patched/R
echo $MAJOR.$MINOR.0 "Patched" > VERSION
cvs commit -m 'prepare for next version' VERSION
# Don't forget this or branch updates run amok!
cvs rtag -F -r $BRANCHTAG last-patch-update R
# Finally, update the developer homepage with new version info
# Make announcement on R-announce
# ------------ All done --------------
</kbd></pre>
<h3> Dot-dot release (x.y.z) </h3>
<pre><kbd>
# Exec the following and check carefully:
MAJOR=1
MINOR=9
PL=1
OPL=$[PL-1]
VERSION=$MAJOR.$MINOR.$PL
OVERSION=$MAJOR.$MINOR.$OPL
TAG=R-$MAJOR-$MINOR-$PL
REL=R-$VERSION
OREL=R-$OVERSION
DIFF=R-$OVERSION-$VERSION.diff
echo -e "TAG=$TAG\nREL=$REL\nDIFF=$DIFF"
FTPDIR=/var/rsync/cran/src/base/
# go to the patched directory
cd ~/r-patched
rm -rf BUILD R
cvs -d ~rdevel/CVS-ARCHIVE checkout -Pr R-$MAJOR-$MINOR-patches R
cd R
tools/rsync-recommended
#-- set/check version number and release status
echo $MAJOR.$MINOR.$PL > VERSION
autoconf
mkdir ~/r-patched/BUILD
cd ~/r-patched/BUILD
(../R/configure --enable-maintainer-mode --prefix ~/$REL \
--with-tcl-config=/usr/lib/tcl8.4/tclConfig.sh \
--with-tk-config=/usr/lib/tk8.4/tkConfig.sh
make && make check-all) | tee make.log
cd ~/r-patched/R
cvs update -Pd
cvs commit -m "prepare for release $REL"
#---- at specified time:
cvs update -Pd # watch out for last minute merges - make check if necessary!
cd ~/r-patched/R
cvs tag $TAG
cd ~/r-patched/BUILD
make dist
cp $REL.tar.gz $FTPDIR/$REL.tgz
cd ../R
cp README INSTALL RESOURCES NEWS Y2K $FTPDIR
cd $FTPDIR
split -b 1400k $REL.tgz $REL.tgz-split.
ln -sf $REL.tgz R-latest.tgz
#---- Setup for patch tree
cd ~/r-patched/R
echo $MAJOR.$MINOR.$PL Patched > VERSION
cvs commit -m "setup for patched versions"
# Finally,
# Update the developer homepage with new version info
# Make announcement on R-announce
# ------------ All done --------------
<h3> Handling experimental branches </h3>
<pre><kbd>
Suppose you want to have a branch to hold your volatile changes, let's
say R-Tk.
(A) Creating the branch
===================
CVSROOT=cvs.r-project.org:/home/rdevel/CVS-ARCHIVE</tt><br>
export CVSROOT
cvs rtag -b R-Tk R
mkdir r-experimental
cd r-experimental
cvs checkout -P -r R-Tk R
cvs rtag -r R-Tk R-Tk-update-last R
(B) Hacking on the branch
=====================
Just like on the release branch:
cvs update -Pd -r R-Tk
#..hack, hack, hack....
cvs commit -m'hacked blah'
(C) Updating from r-devel (aka "main trunk")
========================================
cvs rtag -F R-Tk-update R
cvs update -Pd -j R-Tk-update-last -j R-Tk-update
# resolve conflicts if any
cvs commit -m 'merged from main'
cvs rtag -F -r R-Tk-update R-Tk-update-last R
(D) Merging the hack back into r-devel
==================================
cd ~/r-devel/R
cvs update -Pd -j R-Tk # resolve conflicts if any
cvs commit -m'merged with Tk branch'
</kbd></pre>
</body>
</html>