RE: Problems building ghc-current
The problem is that >ghc<, >green-card<, >hood< et al. are subdirectories of >fptools<, that's why >cvs update -d< retrieves them automatically. I guess a more appropriate repository layout would be _flat_, like this:
/cvs --+ | +-- CVSROOT | +-- fptools | +-- ghc | +-- libraries | +-- hslibs | +-- green-card [...]
Hmm, that sounds like a very good idea. I think perhaps we were fixated on having the same repo layout as the source tree when we originally checked everything into CVS. We could just rearrange the repository in place, and everything would still work, right? Well, perhaps the script that generates the CVS commit logs would have to be tweaked. Cheers, Simon
Simon Marlow writes:
We could just rearrange the repository in place, and everything would still work, right?
It's not quite that easy, unfortunately. If you want to retain the files's version history (and I guess you would), then you have to move the directories around in the CVS repository's file system _directly_, because CVS has no notion of "moving" entries -- let alone directories. As a result, users who have a checked-out copy of the repository, will not be able to commit their changes (or update their copy) anymore, because the paths stored in their "CVS/Repository" files became incorrect. Either, one provides a short shell script to fix this (no big deal), or the repository has to be checked-out from the scratch, before it can be used again. But that's more of a nuisance than a real problem. Peter P. S.: In your quote my '»' and '«' characters were messed up, so I'll be using normal quotes from now on, assuming that the guillemots cause problems on non-Latin-1 systems.
Simon Marlow writes:
We could just rearrange the repository in place, and everything would still work, right?
It's not quite that easy, unfortunately. If you want to retain the files's version history (and I guess you would), then you have to move the directories around in the CVS repository's file system _directly_, because CVS has no notion of "moving" entries -- let alone directories.
Yes, I'm aware of that - I'm no stranger to direct repository surgery ;-)
As a result, users who have a checked-out copy of the repository, will not be able to commit their changes (or update their copy) anymore, because the paths stored in their "CVS/Repository" files became incorrect.
Good point. Cheers, Simon
"Simon Marlow"
/cvs --+ | +-- CVSROOT | +-- fptools | +-- ghc | +-- libraries | +-- hslibs | +-- green-card [...]
We could just rearrange the repository in place, and everything would still work, right? Well, perhaps the script that generates the CVS commit logs would have to be tweaked.
Don't forget that any scripts/Makefiles that refer to ../something may need to change to ../fptools/something. Examples might include the global `mk' files, glafp-utils, and so on. Of course, those could all live at the new toplevel as well, provided that checking out the 'fptools' project collected all of them in one operation. Regards, Malcolm
participants (3)
-
Malcolm Wallace -
Peter Simons -
Simon Marlow