cpphs now in CVS

[Sven Panne]

Malcolm Wallace wrote:
> Well, I still don't understand why symlinks are evil, and locks
> have never yet caused me a problem [...]

I don't understand every detail of CVS' locking mechanism (there are read and
write locks AFAIK), but consider the following scenario:

    * a/b/C.hs is a symlink to d/C.hs (relative to the root of the repository)

    * You try to commit a change to a/b/C.hs. CVS uses a lock in a/b for this.

    * At almost exactly the same time do I try to commit my change to d/C.hs.
      This time, CVS uses a lock in d.

Voila! Two locks for the same file... I'm not sure *what* exactly can happen
and the scenario is not very likely, but it makes me feel a bit uneasy...

Symlinking might even work with respect to locking when you symlink to a whole
directory, but this is exactly the part which is easily handled by CVS modules.

> Yes, it is almost right.  That is, it seems to work nicely for
> grafting directories, but doesn't work at all as expected for grafting
> individual files, e.g. the template-hsc.h entry. [...]

I must admit that I only tested the checkout, not updating. :-[ And thinking a
bit about it, it's clear that grafting only works for whole directories, because
CVS manages some information about files only per directory (see the files
CVS/Repository and CVS/Root).

There are currently two "evil links" left in nhc98 (template-hsc.h and Main.hs,
both from GHC's hsc2hs directory). I'd like to propose that you move nhc98's
hsc2hs Makefiles to the "real" hsc2hs directory (renaming Makefile a bit, of
course :-) and simply graft the whole hsc2hs directory into nhc98. Then you
have all you need, only nhc98's toplevel Makefile needs some adaptation.

Cheers,
    S.