OS/2 Professional/OS2PRO194.ISO/os2/prgramer/cvsdos/readme.too

Text File | 1994-01-18 | 8KB | 185 lines

This info is scheduled to be added to the CVS faq.

1. The Port

Lutz Gruenenberg made a first attempt to port CVS 1.3. I found his
work when I was looking into CVS because I needed a way to collect
all my RCS files in a more easy to use manner.
Lutz' port soon turned out to be a very rough one, so I started
communicating with him about parts I fixed. He then asked me to
maintain this port, since he was in serious lack of time. So I did.
Most of the work went into dealing with 8.3 file naming on DOS
and OS/2 FAT systems. Both version handle this well now, though
some compromises had to be made, and the OS/2 version also supports
the original names on the HPFS. In fact, the OS/2 version has a
switch to choose between short or long names on the HPFS.
A serious shortcoming of DOS is the 640k barrier, that can't be
circumvented unless a DPMI compiler is used. I haven't got one
(yet) so can't work on this yet. I did manage to use an alternative
spawn function, that swaps the current program out to XMS, EMS or
disk before it calls a sub program, so that allows at least some
work to be done. In combination with a DPMI compliant diff
(Kai Uwe Rommel developed one) this will make CVS viable even on
DOS systems. There can, however, be done some optimisation on
CVS itself, as it seems rather inefficient in its use of the stack.
The complete source will be available from ftp.rrzn.uni-hannover.de
as long as Lutz keeps making space available. It will be
in both /pub/msdos-local and /pub/os2-local.
I also upload to ftp-os2.cdrom.com, but rrzn might be more up
to date on occasion.

2. Special considerations

2.1 OS/2

The only consideration for OS/2 is whether or not one uses the
HPFS or the FAT system.
When using the HPFS CVS 1.3 functions exactly the same as it
would on Unix systems. The same naming scheme holds, no special
memory considerations, in short, nothing to worry about.
When using the FAT system, the same story for DOS holds where
file names are concerned.
When using a mix of both, there are two possibilities. Either
you keep the repository on FAT or you keep it on HPFS.
If you keep it on FAT you are forced to always use short names,
even if your working dir is on HPFS.
If you keep it on HPFS you again have two options. Either
you do or do not use short names. If you do, then that part
of the repository you want to work on has to be in short name
format, ie. using an RCS subdir. If you do not, then the
opposite has to be the case.
So, you cannot checkout from a long name repository onto a
FAT file system, but you can checkout from a short name
repository onto HPFS.
CVS could be modified to always use the short name version
for the repository, and allow for both version in the working
dir, and it could also be modified to auto-detect HPFS or
FAT. Neither has been done yet, and ideas or preferences on
why this should be done are welcome.

An extra consideration for OS/2 is the fact that you can also
run DOS software under OS/2. This means that the DOS version
of CVS can be used under OS/2, instead of the OS/2 32-bit
binary, and it may also have as a consequence that DOS software
is used for development. The former is ill-advised because
the DOS version has severe limitations compared to the OS/2
version. See the section on DOS. The latter implies that
short names might be preferable to prevent naming conflicts.
The best solution to this is to always use the 32-bit OS/2
version of CVS, possibly using the short names option.
This removes all the limitations of the DOS version, and
if source names are chosen wisely, there will be no naming
conflicts.

A known, yet not resolved, conflict under OS/2 is the case
retentiveness of the file system. I have not yet found
a satisfactory solution to this. Prerequisites are that
the case is retained on HPFS, yet case insensitivity
is used internally. Any ideas are welcome.

2.2 DOS

The DOS version is a special case of the OS/2 version. File
names have to always confirm with 8.3 conventions. There
is also the 640k barriere to be dealt with.
If one uses the EMX binary than the memory limit is not
there.

2.2.1 DOS file system limitations

First implication of this is that the ,v files are unusable.
RCS solves this by setting the extension to be void (RCSINIT=-x/).
RCS then uses a seperate subdir, RCS, to put it's files in,
instead of the default.
So a repository that would look like this on Unix:

%CVSROOT/module_1               ,v RCS files
    |       |---/module_1.1     ,v RCS files
    |---/module_2               ,v RCS files
    |---/module_3               ,v RCS files

Would look like this on DOS:

%CVSROOT/module_1/RCS           RCS files
    |       |---/module_1.1/RCS RCS files
    |---/module_2/RCS           RCS files
    |---/module_3/RCS           RCS files

No big problem there.
Some of the files in %CVSROOT/CVSROOT had to be renamed because they
where to long:

    commitinfo  -> commitin.fo
    cvsignore   -> ignore.cvs

Also, some of the local administrative directory and file names had
to be changed:

    CVS/Entries.Backup  -> CVS/Entries.Bak
    CVS/Entries.Static  -> CVS/Entries.Sta
    CVS/Repository      -> CVS/Reposit.ory
    CVS/Checkin.prog    -> CVS/Checkin.prg
    CVS/Update.prog     -> CVS/Update.prg
    .cvsignore          -> ignore.cvs

The .p and .t files that are use to mark added files have been
changed to use P and T subdirs instead.
As are the merge backup files. Now a directory named Merge.Bak is
created in which the backups are placed. No attempt was made to
retain the version number, as this presents the problem of
both multiple dots in file names, as well as again exceeding the
8.3 convention. Instead it is assumed that once a new merge is
done, the previous backups are either no longer necessary, or
if they are, the have been moved by hand to keep them available.
A new merge will therefore overwrite any previous file of the
same name, possibly being of another version number.

Lock files have also changed name and form. Locks are now of
the form XXXXX.[rwt]fl, instead of #cvs.[rwt]fl.XXXXX and
#cvslock instead of #cvs.lock.

2.2.2 DOS memory limitations

Using CVS one becomes painfully aware of the 640k barriere.
CVS isn't exactly economical with regards to memory. It uses
a large stack for recursion purposes. On top of that it
calls sub programs that in turn may call another sub program.
Example: on checkin, cvs calls RCS' ci, that in turn calls
diff.
The latter is especially waistfull with memory. Diff reads
both files in their entirety, resulting in memory problems
on even moderate sized files.
Some of CVS' internals have been modified to solve some
major problems. For instance, a swapping spawn is used
to swap CVS out to XMS, EMS or disk before an external
command is run. This gives us some slack, but not enough
to work with large files. For this, diff has to be fixed.
Kai Uwe Rommel developed a DPMI compliant diff that
will most likely remove this problem.
In turn CVS can be optimised to use less (unnecessary) memory,
and it can be made DPMI compliant. Neither is done yet.
One can use gcc/emx for compilation. As emx is a DOS extender,
the memory limit is raised.

2.2.3 DOS command line limitations

A severe handicap is the 127 character limit on the command line.
This makes it next to impossible to use a reasonably sized
log message.
This problem can only be solved if RCS allows for comments to be
read from a file.





ir. E. van Linstee           | Delft University of Technology
Man Machine Consultancy      | I'll be back ...
----
   We are god, 'cause only we can create the idea of his existence
   in our holy brains...  (Yello)
----
   Gentlemen! You cannot fight in here. This is the war-room!  (P.Sellers)