According to Ludovic Courtès: > As someone mentioned, GCC could certainly be split into a number of > projects. This could have a positive impact on code quality -- the APIs > would have to be well-thought, things would have to be "librarified" as > Tom would say, which means that various components could be untangled > and made independent and reusable. The same goes for Linux: why do all > these drivers, filesystems, etc. _have to_ be within the kernel tree?
I have in mind a specific example: /usr/ports in FreeBSD. It is a CVS repository with more than 124000 files in it in more than 32000 directories. We could split it several different ways: at the port level, at the category level and so on but we'd lose the atomic commit feature and changeset generation, that is unacceptable IMHO. > Of course, one may argue that it's not the job of the revision control > tool to advocate a way to organize projects. Arch is doing it by forcing people to think in terms of c--b--v. This is one of its main selling point! > Arch' configs help keep track of dependencies, more than working around > a performance problem. It is more showing a set of categories as a single tree (or set of trees) and I think we lose too much in the process. It is pretty close to CVS modules (although c--b--v is a module in itself too). -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] Darwin snuadh.freenix.org Kernel Version 7.9.0: Wed Mar 30 20:11:17 PST 2005 _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
