Concurrent Versions System (CVS) ported to Microsoft Windows NT Check the ../INSTALL file for information on the most recent version of CVS which has been known to be tested with NT and/or Win95. This port implements the full set of CVS commands, both local and client. It does not provide a CVS server for NT. Multiple users can access a common CVS repository, if they can mount the repository, either directly or via a networked file system. We don't distribute a .ZIP source distribution partly because, as far as I can tell, PKZIP insists on munging long file names, which would confuse the makefile for Visual C++. To compile, use Microsoft Visual C++ on the file cvsnt.mak in the distribution's top directory. At least with the tar port I'm using, the sources get extracted without carriage returns and you must add carriage returns to the end of every line in cvsnt.mak. It doesn't seem to be necessary to add them to any other file. This makefile was generated with Visual C++ 4.x. For Visual C++ 5.x you can try cvsnet.dsp. For Visual C++ 2.x you probably are in the position of digging through old versions of CVS for a cvsnt.mak and then updating it. Feel free to let us know about problems of this sort as with other bug reports. Update as of 13 Oct 1998: I (Jim Kingdon) do build CVS successfully with Visual C++ on a regular basis. The builds on download.cyclic.com (CVS 1.10, CVS 1.10.3, &c) are built using Visual C++ 4.0 and cvsnt.mak from the Debug (not release) configuration. I have pretty much given up on getting the Visual C++ IDE to generate a makefile that works for anyone except me :-(. If I knew an easy fix for this, I'd do it, but it is easier to just complain about Microsoft's finicky IDE and makefile/project file format du jour :-). Having people send in "fixed" versions of cvsnt.mak and cvsnt.dsp regularly, as has been happening, is fine but it isn't an "easy fix", unfortunately, as it is rarely clear to me whether a particular submission will improve things or not. Send bug reports to bug-cvs@gnu.org. As of May 1996, this port passed all of the tests in src/sanity.sh, save the one that deals with reserved all-upper-case tags (BASE and HEAD), due to a limitation in the NT command shell. sanity.sh provides pretty minimal feature coverage, but still gives me some confidence it isn't totally broken. The tests were run by defining KLUDGE_FOR_WNT_TESTSUITE (see src/main.c). To operate in client mode with old versions of CVS (1.9 and older), you will need GNU patch. To do compressed transfers with old versions of CVS (1.8 and older), you also need gzip. Note that you do NOT need an rsh client if you are using the :server: access method (which uses the internal rsh client), except perhaps for debugging. To operate in local mode, you should need nothing other than CVS (that is, you no longer need RCS, diff, &c, in order to run CVS). One useful site may be the Congruent ports of various packages to Windows NT, binary and source: ftp://microlib.cc.utexas.edu/microlib/nt/gnu/ In particular, microlib seems to have versions of GNU tar and gzip which support long file names, which you will need to unpack the CVS source distribution. The CYGWIN32 package is a port of various GNU tools for NT, providing bash as the shell and gcc as the compiler. Basically, you don't want the stuff in this directory for CVS running under cygwin32; you want the same stuff as for unix (../configure, Makefile.in, &c). For cygwin32 information see http://www.cygnus.com/misc/gnu-win32/ Morten Hindsholm's port of CVS 1.4A2 to Windows NT may be useful if you're modifying CVS itself: ftp://ftp.digex.net/pub/access/schueman/cvs/cvsnt14b.zip Here are some other things which may be of interest for unix junkies: http://www.halcyon.com/gvr/vim/ (VI clone) ftp://wuarchive.wustl.edu/systems/ibmpc/gnuish/less177.zip If you want to browse/edit the sources using Visual C++, we recommend setting tab stops to 8 spaces, since that is what the CVS sources expect. The tab stop setting is in the "Editor" or "Tabs" section of the "Options..." dialog which is in the "Tools..." menu. The following harmless warnings are known: - regex.c: 103 warnings, mostly signed/unsigned comparison conflicts. I am not going to *touch* this code. :-) I got my fill of it when I was hacking GNU Emacs. .\lib\getdate.c(760) : warning C4013: 'getdate_yyparse' undefined; assuming extern returning int .\lib\getdate.c(1612) : warning C4102: 'yyerrlab' : unreferenced label .\lib\getdate.c(1612) : warning C4102: 'yynewstate' : unreferenced label Oct 1998 update: there are more now. I've gotten lax about removing the warnings lately :-( -kingdon. CODING STANDARDS for Windows For general coding standards, see ../HACKING. In my opinion win32 is the right API to write to. Microsoft seems to be better about compatibility across versions than unix vendors (on a good day, anyway)--the Visual C++ package I bought has not only win32 but also win16 too (that is, they also include Visual C++ 1.x). As far as I know there is only one win32 (not counting win32s or win32c or whatever), not multiple versions. ANSI C is also good. As far as I know these calls work fairly well on NT. What one should avoid like the plague on NT (IMHO) is POSIX calls such as stat(). These tend to be very poorly supported, and tend to break from version to version or vendor to vendor (the latter being particularly an issue on OS/2, with IBM, Watcom, and EMX all having _very_ different C libraries).