[SPAM] Re: [PATCH] Abstract out a display-table-specific API (2)

Aidan Kehoe writes: That's the best solution, but IIRC Gnus currently aims at supporting Emacs 21, 22, and 23, as well as multiple XEmacsen---spanning about four different redisplay mechanisms. Expect difficulties in getting it right. :-( Mike, although CVS has a lot of problems, its merge capabilities are not much worse than any other system (in principle, anyway, assuming you don't interact with a CVS bug). For this kind of thing, you shouldn't have to actually worry about the merge very often---CVS will take care of it. The simplest thing to do is make a "vendor branch" which does nothing but track upstream's releases, then merge that into the XEmacs CVS mainline. However, my advice would be to keep a private Mercurial (or other modern system) repository. I know from tracking emacs-devel discussions that Emacs Gnus (not to be confused with larsi Gnus, unfortunately) is moving a lot of libraries traditionally provided by Gnus into other parts of Emacs. We've done the same but I'm pretty sure that the Emacs guys are making somewhat different decisions. I suspect that this may end up being reflected upstream in Gnus itself. This means that a SCM that can explicitly track file renames may be of great help. I haven't run into that myself (I've done renames, but never had any imposed on me) so I hesitate to make recommendations, but I know that git, Mercurial, and Darcs all have explicit "rename" commands, and I believe bzr does too. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta