I'm moving this to xemacs-beta and making it a c-f-v because I think a couple of non-reviewers have also mentioned it. If you're one of those folks whose preferred language is Bourne sh or make rather than Lisp or C, this may be your chance to contribute! We are *not* yet committed to actually do anything about it, so don't break your brain researching it. But anybody who knows anything about managing nested projects in hg is invited to comment so we can get a better idea of what we're looking at. Vin Shelton writes: Unfortunately, it is another story. AFAICS hg doesn't support nested projects well (this is not yet another hg whine; git support is minimal, bzr is under development, and darcs non-existent -- it just doesn't seem to be something that DVCSes care about yet). I see three broad ways to go about it. (1) Have a monolithic package tree in a single repo. This doesn't bother me, but it seems kinda unfriendly to people with less than great bandwidth. (2) Participate in hg development and get better support for nested repos. (3) Have a packages repo, whose content includes just the highlevel Makefiles and compile infrastructure, and add a "populate" target which hg clones all of the requested packages. (By "requested" I mean that this target could support the NONMULE_PACKAGES (default xemacs-packages, ie, all) and MULE_PACKAGES (default mule-packages) make variables the way the build and install targets currently do.) There may be other better ways, but (3) seems to me to prove that it's feasible and could be practically reasonable for casual contributors and external maintainers. Comments (and volunteers to implement ;-) welcome! Cheers, Steve _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta