Re: Identify XEmacs build from Mercurial changeset

Michael Sperber writes: How should I know? I have no way to access documentation or test. It's not my problem to solve, although I'm certainly in favor of solving it. I don't see why horrible kludges we use to keep psychotic Windows sedated has to seep over to merely neurotic *nix code. If we have to do things differently for native Windows, what else is new? We've got that whole xemacs.mak horror anyway, with its eight different ways to express "cp -r" depending on Windows version. I'm proposing that we can get rid of the rather yucky file that must not be terminated with a newline by simply adding variable assignments at the end. Last one wins, right? Yes, for this purpose they count as releases. They are currently flagged by the *absence* of xemacs_extra_name. Each beta release is tagged in CVS with "r${MAJOR}-${MINOR}-${MICRO}". In CVS of course this is an absolute necessity, since only tags can be common across files. In hg we revision trees, so we have a repo-local sequence number and a global node id (hash) that we could use, but I still plan to tag betas with the same format. (There have been no releases from the hg repo, of course.) Sure, by trying to check it out and failing if it's not ours. But that means all we know about the repo is the last release. This is just an inherent problem with distributed version control. _______________________________________________ XEmacs-Patches mailing list XEmacs-Patches(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-patches