Malcolm Wallace wrote:

...

...

[...] You can make symlinks within the CVS repository if you need to, as I have already done to ensure that nhc98/src/cpphs points to the master copy of the sources.

Huh? Symlinks? Modules are the usual way to tie together different directories in CVS...

Can't say I ever fully understood the concept of CVS modules. So how would I (for instance) graft the hierarchical libraries, hsc2hs, and cpphs into the source tree of nhc98, all of which are currently symlinks?

I just had a look at the repository structure and only now I fully realize what you mean by symlinking in the repository. This is evil and confuses CVS quite a bit! :-] You get e.g. locks *per directory* in the repository, but with the Evil Symlinking (tm) you get several locks for one entity, which is hardly what is intended. After fiddling around quite a bit with the syntax of the module file, I've added an example module "nhc98all" which does almost what you want: -- CVSROOT/modules ----------------------------------------------------------------- ... nhc98only -d nhc98_ nhc98 nhc98cpphs -d nhc98_/src/cpphs_ cpphs nhc98hsc2hs -d nhc98_/src/hsc2hs_ fptools/ghc/utils/hsc2hs nhc98libraries -d nhc98_/src/libraries_ fptools/libraries nhc98template -d nhc98_/script_ fptools/ghc/utils/hsc2hs template-hsc.h nhc98all -a nhc98only nhc98cpphs nhc98libraries nhc98hsc2hs nhc98template nhc98template ------------------------------------------------------------------------------------ Using "cvs -d ... co nhc98all" yields a nh98_ directory with the various parts grafted to the right places. The lines containing "-d" are sub-modules for the various parts moved to the right place, and the final module simply collects them all. The underscores are only a temporary measure while the old (evil :-) stuff is still there. You can changes this when the symlinks are removed. There are a few other symlinks in the repository (e.g. HaXml), we should fix them, too. Cheers, S.

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.