summaryrefslogtreecommitdiff
path: root/gnu/usr.bin/cvs/INSTALL
blob: 8bb34777f54ecd6e73b0ac635cb77c5f6d3e4b44 (plain)
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
First, read the README file.  If you're still happy...

CVS has been tested on the following platforms.  The most recent
version of CVS reported to have been tested is indicated, but more
recent versions of CVS probably will work too.  Please send updates to
this list to info-cvs@prep.ai.mit.edu.

Alpha:
	DEC Alpha running OSF/1 version 1.3 using cc (about 1.4A2)
	DEC Alpha running OSF/1 version 2.0 (1.4.90)
	DEC Alpha running OSF/1 version 2.1 (about 1.4A2)
	DEC Alpha running OSF/1 version 3.0 (1.5.95) (footnote 7)
HPPA:
	HP 9000/710 running HP-UX 8.07A using gcc (about 1.4A2)
	HP 9000/715 running HP-UX 9.01 using gcc (about 1.4A2)
        HPPA 1.1 running HP-UX A.09.03 (1.5.95) (footnote 8)
	NextSTEP 3.3 (1.4.92, a few tweaks needed)
i386 family:
	Gateway P5-66 (pentium) running Solaris 2.4 using gcc (about 1.4A2)
	PC Clone running UnixWare v1.1.1 using gcc (about 1.4A2)
	PC Clone running ISC 4.0.1 (1.5.94)
	PC Clone running Fintronic Linux 1.2.5 (1.5)
	PC Clone running BSDI 2.0 (1.4.93) (footnote 5)
	PC Clone running Windows NT 3.51 (1.5 client)
	FreeBSD 2.0.5, i486, gcc (1.5.95)
	NextSTEP 3.3 (1.4.92, a few tweaks needed)
	SCO Unix 3.2.4.2 (1.4.93) (footnote 4)
	SCO OpenServer 5.0.0, "CC='cc -b elf' configure"
m68k:
	NextSTEP 3.3 (1.4.92, a few tweaks needed)
m88k:
	Data General AViiON running dgux 5.4R2.10 (1.5)
	Harris Nighthawk 5800 running CX/UX 7.1 (1.5) (footnote 6)
MIPS:
	DECstation running Ultrix 4.2a (1.4.90)
	DECstation running Ultrix 4.3 (1.5)
	SGI running Irix 4.0.5H using gcc and cc (about 1.4A2) (footnote 2)
	SGI running Irix 5.3 (1.4.93)
	SGI running Irix-6 (about 1.4.90) (footnote 3)
PowerPC or RS/6000:
	IBM RS/6000 running AIX 3.2.5 (cc=xlc, CVS 1.5)
	IBM RS/6000 running AIX 4.1 using gcc and cc (about 1.4A2) (footnote 1)
SPARC:
	Sun SPARC running SunOS 4.1.3, 4.1.2, and 4.1.1 (1.5)
	Sun SPARC running SunOS 4.1.3, w/ bundled K&R cc (1.5.94)
	Sun SPARCstation 10 running Solaris 2.3 using gcc and cc (about 1.4A2)
	Sun SPARCstation running Solaris 2.4 using gcc and cc (about 1.5.91)
	NextSTEP 3.3 (1.4.92, a few tweaks needed)

(footnote 1)
	AIX 4.1 systems fail to run "configure" due to bugs in their
	"/bin/sh" implementation.  You might want to try feeding the
	configure script to "bash" ported to AIX 4.1.  (about 1.4A2).

(footnote 2)
	Some Irix 4.0 systems may core dump in malloc while running
	CVS.  We believe this is a bug in the Irix malloc.  You can
	workaround this bug by linking with "-lmalloc" if necessary.
	(about 1.4A2).

(footnote 3)
        There are some warnings about pointer casts which can safely be
        ignored.  (about 1.4.90).

(footnote 4) Comment out the include of sys/time.h in src/server.c. (1.4.93)
	You also may have to make sure TIME_WITH_SYS_TIME is undef'ed.

(footnote 5) Change /usr/tmp to /var/tmp in src/server.c (2 places) (1.4.93).

(footnote 6) Build in ucb universe with COFF compiler tools.  Put
	/usr/local/bin first in PATH while doing a configure, make
	and install of GNU diffutils-2.7, rcs-5.7, then cvs-1.5.

(footnote 7) Manoj Srivastava <srivasta@pilgrim.umass.edu> reports
        success with this configure command:
  CC=cc CFLAGS='-O2 -Olimit 2000 -std1' ./configure --verbose alpha-dec-osf

(footnote 8) Manoj Srivastava <srivasta@pilgrim.umass.edu> reports
        success with this configure command:
  CC=cc CFLAGS='+O2 -Aa -D_HPUX_SOURCE' ./configure --verbose hppa1.1-hp-hpux

-------------------------------------------------------------------------------

Installation under Unix:

1)  Run "configure":

	$ ./configure

    You can specify an alternate destination to override the default with
    the --prefix option:

	$ ./configure --prefix=/usr/local/gnu

    or some path that is more appropriate for your site.  The default prefix
    value is "/usr/local", with binaries in sub-directory "bin", manual
    pages in sub-directory "man", and libraries in sub-directory "lib".

    This release of CVS also requires RCS commands to be installed in
    the user's PATH (or a path you have configured in src/options.h).
    If you don't have RCS, you will need to get it from GNU as well.
    It is best to get the version 5.6.0.1 (or later) version of RCS,
    available from prep.ai.mit.edu in the file
    pub/gnu/rcs-5.6.0.1.tar.Z.  It is best (although not essential) to
    avoid RCS versions 5.6.[5-7] beta because the rcsmerge therein
    defaults to -A instead of -E which affects the way CVS handles
    conflicts (this is fixed in RCS 5.6.8 and RCS 5.7).  Along with
    RCS, you will want to run GNU diff.  This will allow revision
    control of files with binary data (a real nice feature).  You will
    need at least version 1.15 of GNU diff for this to work.  Be sure
    that you configure RCS to work correctly with GNU diff to avoid
    other configuration problems.  If you are running RCS 5.7, you
    should be aware that you must supply a log message containing at
    least one non-whitespace character (CVS catches some, but not all,
    cases).  This has always been a problem but the symptoms are
    apparently more severe with RCS 5.7.  This is expected to be fixed
    in a future CVS release.

    If you are using the remote client, you will need a version of
    patch which understands unidiffs (such as any recent version of
    GNU patch).

    NOTE: The configure program will cache the results of the previous
    configure execution.  If you need to re-run configure from scratch, you
    may need to run "make distclean" first to remove the cached
    configuration information.

    NOTE ON CVS's USE OF NDBM:

	By default, CVS uses some built-in ndbm emulation code to allow
	CVS to work in a heterogeneous environment.  However, if you have
	a very large modules database, this may not work well.  You will
	need to edit src/options.h to turn off the MY_NDBM #define and
	re-run configure.  If you do this, the following comments apply.
	If not, you may safely skip these comments.

	If you configure CVS to use the real ndbm(3) libraries and
	you do not have them installed in a "normal" place, you will
	probably want to get the GNU version of ndbm (gdbm) and install
	that before running the CVS configure script.  Be aware that the
	GDBM 1.5 release does NOT install the <ndbm.h> header file included
	with the release automatically.  You may have to install it by hand.

	If you configure CVS to use the ndbm(3) libraries, you cannot
	compile CVS with GNU cc (gcc) on Sun-4 SPARC systems.  However, gcc
	2.0 may have fixed this limitation if -fpcc-struct-return is
	defined.  When using gcc on other systems to compile CVS, you *may*
	need to specify the -fpcc-struct-return option to gcc (you will
	*know* you have to if "cvs checkout" core dumps in some ndbm
	function).  You can do this as follows:

	    $ CC='gcc -fpcc-struct-return' ./configure

	for sh, bash, and ksh users and:

	    % setenv CC 'gcc -fpcc-struct-return'
	    % ./configure

	for csh and tcsh users.

    END OF NOTE FOR NDBM GUNK.

2)  Edit src/options.h.  Appropriate things to look at may be the
    invocation locations of programs like DIFF, GREP, RM, and SORT.
    Also glance at the default values for the environment variables
    that CVS uses, in particular, the RCSBIN variable, which holds the
    path to where the RCS programs live on your system.  The
    likelihood is that you don't have to change anything here, except
    perhaps adding the -a option to DIFF if you are using GNU diff.

3)  Try to build it:

	$ make

    This will (hopefully) make the needed CVS binaries within the "src"
    directory.  Send me your "config.status" file with your host type,
    operating system information, and make output if something fails for
    your system.

4)  Install the binaries/documentation:

	$ make install

    Depending on your installation's configuration, you may need to be
    root to do this.

5)  Take a look at the CVS documentation.

	$ man cvs

    and

	$ info cvs  

    See what it can do for you, and if it fits your environment (or can
    possibly be made to fit your environment).  If things look good,
    continue on...

6)  Setup the master source repository.  Choose a directory with ample disk
    space available for source files.  This is where the RCS ",v" files
    will be stored.  Note that this should be some shared directory for your
    site.  It should probably be auto-mounted, if you're running NFS.

    Say you choose "/src/master" as the root of your source repository.
    Run the "cvsinit" script to help you set it up.  It will ask you to
    enter the path to your CVSROOT area.  You would enter /src/master in
    this example.

	$ ./cvsinit

    The cvsinit script will setup a reasonable CVSROOT area to start with.
    It is also valuable to folks who already have a CVSROOT area setup from
    using earlier releases of CVS.  It assumes that you have installed CVS
    already (step 4) and that the RCS programs (co and ci) are in your
    PATH.  There are many ways to customize CVS for your site.  Read the
    cvs(5) manual page when you get the chance.

7)  Have all users of the CVS system set the CVSROOT environment variable
    appropriately to reflect the placement of your source repository.  If
    the above example is used, the following commands can be placed in
    user's ~/.profile, ~/.bash_profile, or ~/.login file:

	CVSROOT=/src/master; export CVSROOT

    for sh/bash/ksh users, or

	setenv CVSROOT /src/master

    for csh/tcsh users.  If these environment variables are not already set
    in your current shell, set them now (or source the login script you
    just edited).  You will need to have the CVSROOT environment variable
    set to continue on to the next step.

8)  It might be a good idea to jump right in and put the CVS distribution
    directly under CVS control.  From within the top-level directory of the
    CVS distribution (the one that contains this README file) do the
    following commands:

	$ make distclean
	$ cvs import -m 'CVS 1.4 distribution' cvs CVS CVS1_4

9)  Having done step 8, one should be able to checkout a fresh copy of the
    CVS distribution and hack away at the sources with the following command:

	$ cd
	$ cvs checkout cvs

    This will make the directory "cvs" in your current directory and
    populate it with the appropriate CVS files and directories.

10) Remember to edit the modules file manually when sources are checked in
    with "cvs import" or "cvs add".  A copy of the modules file for editing
    can usually be retrieved with the "cvs checkout modules" command, and
    definitely with the "cvs checkout CVSROOT" command.  See cvs(5).

11) Read the NEWS file to see what's new.

12) Hack away.

-------------------------------------------------------------------------------

Detailed info about your interaction with "configure":

The "configure" script and its interaction with its options and the
environment is described here.

Supported options are:
	--srcdir=DIR		Useful for compiling on many different
				machines sharing one source tree.
	--prefix=DIR		The root of where to install the
				various pieces of CVS (/usr/local).
	--exec_prefix=DIR	If you want executables in a
				host-dependent place and shared
				things in a host-independent place.

The following environment variables override configure's default
behaviour:
	CC			If not set, tries to use gcc first,
				then cc.  Also tries to use "-g -O"
				as options, backing down to -g
				alone if that doesn't work.
	INSTALL			If not set, tries to use "install", then
				"cp" as a final choice.
	RANLIB			If not set, tries to determine if "ranlib"
				is available, choosing "echo" if it doesn't
				appear to be.
	YACC			If not set, tries to determine if "bison"
				is available, choosing "yacc" if it doesn't
				appear to be.

-------------------------------------------------------------------------------
Installation under Windows NT:

You may find interesting information in windows-NT/README.

1) Using Microsoft Visual C++ version 2.1, open the project `cvsnt.mak',
   in the top directory of the CVS distribution.
2) Choose "Build cvs.exe" from the "Project" menu.
3) MSVC will place the executable file cvs.exe in WinDebug, or whatever
   your target directory is.
-------------------------------------------------------------------------------