All the versions that were in CVS are in the git Repository (if the conversion tool worked correctly). So the following is obsolete for all ordinary purposes.
cvs -d :pserver:anonymous@c1.complang.tuwien.ac.at:/nfs/unsafe/cvs-repository/src-master co gforth
In order to build Gforth, you need to have a moderately recent version of Gforth installed (e.g., from one of the distribution packages). Then you can type
./BUILD-FROM-SCRATCHand ideally, this will build a bleeding-edge version of Gforth. At the time of this writing, this fails (by hanging in an invocation of Gforth), but you can work around this problem by killing the gforth process (e.g., with
killall gforth
on Linux systems) and
then continuing with
make
export CVS_RSH=ssh cvs -d :ext:user@mips.complang.tuwien.ac.at:/nfs/unsafe/cvs-repository/src-master co gforth(where user is your account name on the machine mips).
If you have already done changes to the directory tree you created with the pserver method, and want to check them in, a good way to do it is to change all the CVS/Root files from :pserver:anonymous@c1.complang.tuwien.ac.at:/nfs/unsafe/cvs-repository/src-master to :ext:user@mips.complang.tuwien.ac.at:/nfs/unsafe/cvs-repository/src-master, e.g., like this:
cd .../gforth for i in `find . -name Root -print|grep CVS/Root` do echo ':ext:user@mips.complang.tuwien.ac.at:/nfs/unsafe/cvs-repository/src-master' >$i done
Note that it is a bad idea to separate a file from its CVS directory (e.g., by copying it from the pserver tree to the write-enabled ext tree), because this can lead to inconsistencies (e.g., commiting something derived from an outdated version, thus undoing the changes in between). Yes, I have seen this happen in practice, and the results were unpleasant.