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.