Handy environment (system) variables
People using the CVS command line directly might need to setup a few RISC OS system variables first :
- CVS$ROOT : specifies the CVS' repository which is the directory containing (!) the CVSROOT directory and all the CVS projects stored in that CVS repository (cfr. CVS documentation). If you do not define this, you need to use the "-d" CVS option.
- CVS$Heap : when defined (contents does not matter), CVS will use dynamic area's for storing its application data. It is recommended to define this for RISC OS 3.5 and above users.
- CVS$User : specifies the username which is used during the CVS operations. If you do not define this, the artificial and dull username "uid1" will be used.
- CVS$FFFExt : when defined (contents does not matter), CVS will translate RISC OS text filenames into Unix filenames with ",fff" suffix, similar like it does for all non text filenames. Otherwise text filenames in Unix syntax will not have the ",fff" suffix.
- UnixEnv$cvs$sfix : specifies the which suffixes needs to be swapped. Cfr. "Specific things about the RISC OS Port" section below.
Specific things about the RISC OS Port
The main idea behind the CVS port was to change as less as possible the sources to get it working under RISC OS. Using the latest version of UnixLib this was more or less possible. There are few things which show the consequences of this decision :
- As CVS is very much file operation based and those files are referred using Unix filenames, the RISC OS user needs to specify the files & directories using Unixified RISC OS file/dir names. E.g. :
cvs -d :local:/SCSI::MyHardDisc/$/cvs/cvsroot init
instead of what you may have expected :
cvs -d :local:SCSI::MyHardDisc.$.cvs.cvsroot init
The file & directory specifications shown during the cvs operations will also be in such a Unixified way.
- In order to be slightly more RISC OS compliant concerning environment (system) variables, a second environment lookup is done when the original CVS environment variables can not be found. The following table will make it clear :
First try: Second try:
CVSROOT -> CVS$ROOT
CVS_PASSFILE -> CVS$PASSFILE
CVS$HomeDir <no second try>
TMPDIR -> CVS$TMPDIR
The idea for the user is to use as much the "CVS$" environment (system) variables as possible but still support the CVS Unix compatible environment variables for those who really want.
- When environment (system) variable <CVS$HomeDir> is not defined, but <Choices$Write> is, then cvs will create a sub dir <Choices$Write>.CVS and consider that directory as home dir (where /cvspass is stored). If <CVS$HomeDir> is defined, it should point to a directory holding the /cvspass file.
- Command line CVS users might be pleased to know that it is possible to do "external" edits for entering text in e.g. commits. All you have to do is :
- Either define the system variable EDITOR or CVS$EDITOR, like :
Set CVS$EDITOR <CVS$BinDir>.ee -t "FFF
- Either you specify the editor on the command line itself, like :
cvs -e "<CVS$BinDir>.ee -t "FFF " commit myfile.c
Of course you need an editor loaded which allows external edits (like StrongEd or Zap). This handy "ee" program was written by Justin Fletcher. Thanks Justin !
- As CVS uses filename lengths of more than 10 characters for storing its CVSROOT database, you must use a filing system which is capable of doing this. Personally I've used for a long time raFS on top of a 10-char limited FileCore based FS quite successfully. Now I'm using a long filename FileCore formatted harddisc under RISC OS 4 :-).
Also when you use the ":server:" or ":pserver:" transport mode, you also need a FS which can store sufficent long filename lengths when the source filenames contain more than 10 characters.
- Two enhancements in UnixLib are made for this CVS port :
- Files like main.c (as Unix file spec) are translated into c.main on RISC OS and visa versa.
When you do not want this behaviour and would like to map c.main (RISC OS, filetype 0xFFF) on c/main (Unix) and o.main (RISC OS, filetype 0xFFD) on o/main,ffd (Unix), you need to (re)define the
system variable :
Set UnixEnv$cvs$sfix ""
When the system variable <UnixEnv$cvs$sfix> is not defined, then the implicit default value "a:c:cc:f:h:i:ii:l:o:p:s:y" is used by UnixLib (which leads to the above mentioned extention filename remapping for extentions "a", "c", "cc", "f", "h", "i", "ii", "l", "o", "p", "s" and "y").
Note that earlier versions of CVS used UnixFS$sfix instead of UnixEnv$cvs$sfix. This was a change in UnixLib in GCC RISC OS port.
- A second enhancement is that non text filetyped files on RISC OS get their filetype as a 12 bit hex number to their Unix "equivalent" filename. E.g. : MakeFile (filetype &FE1) on RISC OS has the Unix filename MakeFile,fe1. A second example is o.main (filetype 0xFFD) on RISC OS, which results in the Unix filename main.o,ffd.
This is same filetype mapping as used in the Acorn NFS client.
Watch out for the following Gotcha's
- Do not create projects in the repository with names starting with an exclamation mark (i.e. "!"). You won't be able to do a checkout as "cvs checkout !MyProject" in fact means : do a checkout and ignore the directory "MyProject"...
- Watch out with the following gotcha :
cvs -d /tmp/cvs init
This generates the CVSROOT dir in <Wimp$ScrapDir> (UnixLib maps /tmp to <Wimp$ScrapDir> and visa versa) and this generates several errors if <Wimp$ScrapDir> is located on a disc where you have a limit on the filename length (like the 10 character FileCore limitation). Those errors are typically :
cvs init: ERROR: cannot write file /tmp/cvs/CVSROOT/commitinfo,v: File open
cvs init: ERROR: cannot write file /tmp/cvs/CVSROOT/checkoutlist,v: File open
cvs init: ERROR: cannot write file /tmp/cvs/CVSROOT/cvswrappers,v: File open
cvs [init aborted]: EOF in value in RCS file commitinfo,v
Solution : be explicit in your definition of <CVS$ROOT> or -d argument when specifying the transport mode and if the transport mode is ":local:" use a Unixified RISC OS directory specfication, like :
set CVS$ROOT :local:/AppleFS::Mac/$/cvs
cvs init
or
cvs -d :local:/AppleFS::Mac/$/cvs init
- When you specify compression (the "-z" option) and you get the following error :
cvs [checkout aborted]: compression initialization: error -4
Then make sure you have enough memory allocated in your WimpSlot. Typically 2 - 3 MByte should be enough for modest CVS projects when you have defined CVS$Heap otherwise your wimpslot probably needs to be larger.
Contact the
. Last changes made on 8th September 2004.