-------------------------------------------------------------------------------
IMPORTANT: CVS uses many filenames for its files that are illegal under MS-DOS.
It also uses its own routines instead of an external RCS now, so none of the
 extensions of the DJGPP port of RCS will work.
As such, this port is only suited for use under Win9x with LFNs enabled.
I may try to patch CVS for DOS, but it is unlikely that such an endeavour would
 be simple (or even possible without breaking the code).
-------------------------------------------------------------------------------

This is a port of CVS 1.10 to DJGPP (patchlevel 3).


Building CVS:

This should be as simply as standing in gnu/cvs-1.10 and typing make.
Alternatively, run make separately in the diff, lib, zlib and src directories.
No special tools should be required.


Installing CVS:

Put the executable you built in your path (preferably in $DJDIR/bin). If you
 have the binary distribution, put either cvs.exe or cvsdb.exe from
 contrib/cvs-1.10 in your path as cvs.exe. See point 3) below for information
 on the difference between these executables.
Note: The i686 subdirectory contains PentiumPro-optimized versions of the two
 executables. I'm not sure whether these provide a real speedup (after all,
 CVS is rather I/O-oriented).
I've also included some of the scripts (the few that work and might be useful).


Then edit your djgpp.env file, adding the following lines:

        <global>
        +CVSROOT=%DJDIR%/Versions

        [cvs]
        +CVSEDITOR=pico

The CVSROOT variable tells CVS where to store its configuration as well as
 all its repositories (the RCS files for the projects you manage with CVS).
I use $DJDIR/Versions, but any directory will do (but see the notes below).
 This should be in the global section because other programs may rely on it.

The CVSEDITOR tells CVS what editor to run to edit log entries. If this isn't
 set, CVS will try to use $EDITOR or $VISUAL, finally defaulting to 'vi'. Any
 editor that accepts Unix-style paths will do (ie pico, emacs, possibly RHIDE).
Pico is a good choice since it starts up fast and editing log entries rarely
 requires more than the simple functions it provides. If you have a vi port,
 and feel comfortable using it, feel free to use that instead.

Finally, you should tell CVS to create its configuration files. You do this by
 running
        cvs init
This causes a directory $CVSROOT/CVSROOT to be created and filled with several
 files.

For information on using CVS to manage your projects, see the info file.


-- Original Port -- April 1999 --

The following issues exist:

1) All files are treated as text by default. If you want to put a binary
   file in a CVS repository, you should always use the -kb option when
   adding/importing those files. You can use this same method to use Unix-style
   text files, but do note that -kb disables RCS keyword expansion, which may
   not be what you want.
   For more information, see the 'Binary files' topic in the CVS Info file.

2) CVS 1.10 is distributed with zlib 1.0.4 by default. This DJGPP distribution
   contains zlib 1.1.3. This probably has no effect (DJGPP doesn't support
   CVS servers and since zlib is only used for authentication it shouldn't
   affect this port).

3) CVS maintains some databases about tags and some other things. It can use
   either its own simplified dbms (the default), or use ndbm (or gdbm).
   If you want to use gdbm, you must:
      a) Have the ndbm.h header file. This is only part of the source
          distribution of gdbm (gdbm143s.zip or something similar in the
          Simtelnet gnu/djgpp/v2gnu directory).
      b) Uncomment -lgdbm in src/Makefile (or src/Makefile.in if you have the
          tools required to rebuild the makefiles). You'll need to edit the
          top-level Makefile(.in) as well if you want to build from there
          instead of src/.
      c) Comment out the MY_NDBM define in src/options.h.
   And then recompile the whole thing.
   The gdbm version MAY be slightly more efficient, but if you need this CVS
    to work with other CVS's (for example, if you run both DOS/WinX and Linux
    and want to share repositories between systems), you must make sure all
    copies of CVS use the same setting.
   The binary ditribution contains 2 executables: cvs.exe is the normal one,
    and cvsdb.exe is the one with gdbm support.

4) To reconfigure, you'll need my extensively patched autoconf. It's included
    in the autoconf subdirectory. The scripts should go in your path; the
    files in the share/ directory should go in $DJDIR/share/autoconf.
   Although not needed to reconfigure cvs, I've also included my patched
    aclocal. The script goes in your path; the .m4 files in share/ go in
    $DJDIR/share/aclocal.

5) Only local CVSRoots are supported. The DJGPP port of CVS can not act as a
    server, nor can it act as a client to a CVS server. If you want this
    functionality, build a Win32 version.

6) Many of the scripts in the contrib/ directory don't work under DOS. Since
    you probably have no use for them, this should not be a problem. Also,
    ignore the cvshelp manpage located there; it describes some ancient
    version of CVS.

This port has not yet been extensively tested. The main extant problems will
 likely concern path separators. When adding stuff to a repository, try
 passing the Unix-style path to 'cvs add' to prevent trouble. This version
 is much more DOS-friendly out-of-the-box than its predecessor, but it is
 likely many problems remain.

I am available for bug reports at zastai@hotmail.com. However, I can only log
 on extremely sporadically (about once a month), so replies may be slow at the
 best of times.


-- patchlevel 1 -- January 2000 --

I got a bug report stating that using "R:/" as CVSROOT didn't work. This was
 indeed the case. The problem was that CVS strips the trailing slash from
 CVSROOT; in this case the result wasn't an absolute pathname, which caused
 it to be seen as a remote path (which isn't supported). This has now been
 fixed to some extent (a slash is re-added); while it works it does have the
 side-effect that repository paths will often look like 'D://foo/bar'. I don't
 believe this really breaks anything, but it might. To be safe, use a path with
 at least one subdirectory (eg R:/Repository) for your CVSROOT.

-- patchlevel 2 -- February 2000 --

I noticed a rather serious bug introduced by patchlevel 1: a badly placed
 #endif in the patched code made checkouts impossible. This is fixed.
Also, I encountered trouble re-adding a dead revision; this was caused by an
 attempt to rename an open (cached) RCS file. This now fixed; but the fix may
 entail a performance hit (RCS files are no longer cached by RCS_parse()).

-- patchlevel 3 -- May 2000 --

Updated my included patched aclocal and autoconf.
Rebuilt the binaries using DJGPP 2.03. This means CVS now supports /dev/env
 and the like. To avoid trouble, it is recommended to use a /dev/-style path
 for CVSROOT (eg /dev/env/DJDIR/Versions, /dev/E, or whatever).

Tim "Zastai" Van Holder


MD5 Checksums for the paranoid:
154c396eaeb0b80b6890c01554dcc7e5 *./cvs.exe
8f03e5948105ea9032092648cf55c633 *./cvsdb.exe
8a5b0245a23a3bb17e429bab75cfb49b *./i686/cvs.exe
bb610d33ac52ba4bf966b661720b7638 *./i686/cvsdb.exe
