Call for volunteers: move packages to hg repo?
Stephen J. Turnbull
stephen at xemacs.org
Mon Feb 2 03:48:15 EST 2009
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:
> I'd also like to see us move the packages to hg, but that's another
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
(2) Participate in hg development and get better support for nested
(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!
More information about the XEmacs-Beta