Vin Shelton writes: Seems to me that usage is likely to vary and we should just deal with them case-by-case. In this case if our cperl-mode is quite close to Ilya's version 6.2, just changing to 6.2 as you suggest seems best. But if it's been heavily modified, maybe Ilya doesn't want that (Ilya has not been famous for volunteering to help fix bugs in code that isn't his...). So you see the problem with trying to have a blanket policy, at least without substantial thought about it. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Dear developers - On Thu, Dec 22, 2011 at 10:00 AM, Vin Shelton wrote: Included is the modest list of references to $Revision$ used in code in the packages. I have updated the version numbers to the most recent ones from the released packages. I left out erc because there were too many occurrences and I was too lazy. I'll commit these changes sometime over the weekend unless I hear any objections. By the way, working with the packages in the current repo structure is less than ideal. Here's how I generated this diff: cd ~/scmroot/xemacs-packages for d in *-packages/*(/); do cd $d hg diff cd - done This results in diffs that don't actually say what repository they are against! For instance the first chunk of diffs come from edit-utils, but that is not obvious from the diff. Suggestions welcome. - Vin diff -r 6809d81c434e ChangeLog --- a/ChangeLog Sat Sep 03 14:45:06 2011 +0200 +++ b/ChangeLog Thu Dec 22 15:11:49 2011 -0500 ＠＠ -1,3 +1,9 ＠＠ +2011-12-22 Vin Shelton <acs(a)xemacs.org&gt; + + * allout.el (outline-version): + * winring.el (winring-version): Set $Revision to the most recent + CVS revision number. + 2011-05-11 Norbert Koch <viteno(a)xemacs.org&gt; * Makefile (VERSION): XEmacs package 2.44 released. diff -r 6809d81c434e allout.el --- a/allout.el Sat Sep 03 14:45:06 2011 +0200 +++ b/allout.el Thu Dec 22 15:11:49 2011 -0500 ＠＠ -509,7 +509,7 ＠＠ ;;;_ : Version ;;;_ = outline-version (defvar outline-version - (let ((rcs-rev "$Revision$")) + (let ((rcs-rev "$Revision: 1.1 $")) (condition-case err (save-match-data (string-match "Revision: \\([0-9]+\\.[0-9]+\\)" rcs-rev) diff -r 6809d81c434e winring.el --- a/winring.el Sat Sep 03 14:45:06 2011 +0200 +++ b/winring.el Thu Dec 22 15:11:49 2011 -0500 ＠＠ -8,7 +8,7 ＠＠ ;; Created: March 1997 ;; Keywords: frames tools -(defconst winring-version "$Revision$" +(defconst winring-version "$Revision: 1.2 $" "winring version number.") ;; This file is part of GNU Emacs. diff -r 689c9d91c5de ChangeLog --- a/ChangeLog Sat Sep 03 14:45:55 2011 +0200 +++ b/ChangeLog Thu Dec 22 15:11:50 2011 -0500 ＠＠ -1,3 +1,8 ＠＠ +2011-12-22 Vin Shelton <acs(a)xemacs.org&gt; + + * forms.el (forms-version): Set $Revision to the most recent CVS + revision number. + 2003-10-31 Norbert Koch <viteno(a)xemacs.org&gt; * Makefile (VERSION): XEmacs package 1.15 released. diff -r 689c9d91c5de forms.el --- a/forms.el Sat Sep 03 14:45:55 2011 +0200 +++ b/forms.el Thu Dec 22 15:11:50 2011 -0500 ＠＠ -302,7 +302,7 ＠＠ (provide 'forms) ;;; official (provide 'forms-mode) ;;; for compatibility -(defconst forms-version (substring "$Revision$" 11 -2) +(defconst forms-version (substring "$Revision: 1.3 $" 11 -2) "The version number of forms-mode (as string). The complete RCS id is: $Id$") diff -r c149ad62c874 ChangeLog --- a/ChangeLog Sat Sep 03 14:49:34 2011 +0200 +++ b/ChangeLog Thu Dec 22 15:11:52 2011 -0500 ＠＠ -1,3 +1,8 ＠＠ +2011-12-22 Vin Shelton <acs(a)xemacs.org&gt; + + * net-utils.el (net-utils-version): Set $Revision to the most + recent CVS revision number. + 2008-04-07 Norbert Koch <viteno(a)xemacs.org&gt; * Makefile (VERSION): XEmacs package 1.56 released. diff -r c149ad62c874 net-utils.el --- a/net-utils.el Sat Sep 03 14:49:34 2011 +0200 +++ b/net-utils.el Thu Dec 22 15:11:52 2011 -0500 ＠＠ -71,7 +71,7 ＠＠ (require 'font-lock) (autoload 'ffap-string-at-point "ffap")) -(defconst net-utils-version (substring "$Revision$" 11 -2) +(defconst net-utils-version (substring "$Revision: 1.5 $" 11 -2) "The version number of net-utils (as string). The complete RCS id is: $Id$") diff -r be87a7f039ff ChangeLog --- a/ChangeLog Sat Sep 03 14:50:00 2011 +0200 +++ b/ChangeLog Thu Dec 22 15:11:53 2011 -0500 ＠＠ -1,3 +1,8 ＠＠ +2011-12-21 Vin Shelton <acs(a)xemacs.org&gt; + + * cperl-mode.el (cperl-version): Since mercurial is not doing + keyword expansion, fill the revision in manually. + 2008-04-20 Norbert Koch <viteno(a)xemacs.org&gt; * Makefile (VERSION): XEmacs package 1.14 released. diff -r be87a7f039ff cperl-mode.el --- a/cperl-mode.el Sat Sep 03 14:50:00 2011 +0200 +++ b/cperl-mode.el Thu Dec 22 15:11:53 2011 -0500 ＠＠ -10629,7 +10629,7 ＠＠ (cperl-fontify-syntaxically to))))) (defvar cperl-version - (let ((v "$Revision$")) + (let ((v "$Revision: 6.2 $")) (string-match ":\\s *\\([0-9.]+\\)" v) (substring v (match-beginning 1) (match-end 1))) "Version of IZ-supported CPerl package this file is based on.") diff -r af4ec0ea580f ChangeLog --- a/ChangeLog Sat Sep 03 14:50:20 2011 +0200 +++ b/ChangeLog Thu Dec 22 15:11:53 2011 -0500 ＠＠ -1,3 +1,9 ＠＠ +2011-12-22 Vin Shelton <acs(a)xemacs.org&gt; + + * verilog-mode.el (verilog-mode-version): + * ksh-mode.el (ksh-mode): Set $Revision to the most recent CVS + revision number. + 2011-05-16 Norbert Koch <viteno(a)xemacs.org&gt; * Makefile (VERSION): XEmacs package 2.25 released. diff -r af4ec0ea580f ksh-mode.el --- a/ksh-mode.el Sat Sep 03 14:50:20 2011 +0200 +++ b/ksh-mode.el Thu Dec 22 15:11:53 2011 -0500 ＠＠ -237,7 +237,7 ＠＠ ;; Conception of this mode. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; -(defconst ksh-mode-version "$Revision$" +(defconst ksh-mode-version "$Revision: 1.4 $" "*Version numbers of this version of ksh-mode") ;; ＠＠ -505,7 +505,7 ＠＠ ;;;###autoload (defun ksh-mode () - "ksh-mode $Revision$ - Major mode for editing (Bourne, Korn or Bourne again) + "ksh-mode $Revision: 1.4 $ - Major mode for editing (Bourne, Korn or Bourne again) shell scripts. Special key bindings and commands: \\{ksh-mode-map} diff -r af4ec0ea580f verilog-mode.el --- a/verilog-mode.el Sat Sep 03 14:50:20 2011 +0200 +++ b/verilog-mode.el Thu Dec 22 15:11:53 2011 -0500 ＠＠ -120,7 +120,7 ＠＠ ;;;###autoload(add-to-list 'auto-mode-alist '("\\.\\(vh?\\|svh?\\|dv\\)\\'" . verilog-mode)) ;; This variable will always hold the version number of the mode -(defconst verilog-mode-version (substring "$$Revision$$" 12 -3) +(defconst verilog-mode-version (substring "$$Revision: 463 $$" 12 -3) "Version of this Verilog mode.") (defconst verilog-mode-release-date (substring "$$Date$$" 8 -3) "Release date of this Verilog mode.") diff -r a7ab7206d8fa ChangeLog --- a/ChangeLog Sat Sep 03 14:51:46 2011 +0200 +++ b/ChangeLog Thu Dec 22 15:11:55 2011 -0500 ＠＠ -1,3 +1,8 ＠＠ +2011-12-22 Vin Shelton <acs(a)xemacs.org&gt; + + * folding.el (folding-version): Set $Revision to the most recent + CVS revision number. + 2010-10-19 Norbert Koch <viteno(a)xemacs.org&gt; * Makefile (VERSION): XEmacs package 2.00 released. diff -r a7ab7206d8fa folding.el --- a/folding.el Sat Sep 03 14:51:46 2011 +0200 +++ b/folding.el Thu Dec 22 15:11:55 2011 -0500 ＠＠ -1810,7 +1810,7 ＠＠ (defvar folding-stack nil "Internal. A list of marker pairs representing folds entered so far.") -(defvar folding-version (substring "$Revision$" 11 15) +(defvar folding-version (substring "$Revision: 1.25 $" 11 15) "Version number of folding.el.") ;;}}} diff -r 9c8d90ff0183 ChangeLog --- a/ChangeLog Sat Sep 03 14:54:05 2011 +0200 +++ b/ChangeLog Thu Dec 22 15:11:56 2011 -0500 ＠＠ -1,3 +1,8 ＠＠ +2011-12-22 Vin Shelton <acs(a)xemacs.org&gt; + + * bench.el (bench-version): Set $Revision to the most recent CVS + revision number. + 2011-02-27 Norbert Koch <viteno(a)xemacs.org&gt; * Makefile (VERSION): XEmacs package 1.82 released. diff -r 9c8d90ff0183 bench.el --- a/bench.el Sat Sep 03 14:54:05 2011 +0200 +++ b/bench.el Thu Dec 22 15:11:56 2011 -0500 ＠＠ -340,7 +340,7 ＠＠ ) ;============================================================================= -(defconst bench-version (let ((rcsvers "$Revision$")) +(defconst bench-version (let ((rcsvers "$Revision: 1.4 $")) (substring rcsvers 11 (- (length rcsvers) 2))) "*Version number of bench.el") _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: It's not our decision in most of these cases. I have little objection to removing them from packages maintained by XEmacs Beta (although it will create a minor annoyance of guaranteeing a conflict on every upstream upgrade), though. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Vin Shelton writes: AFAIK you can insert "echo Package: $d" here without confusing either people or machines. Isn't this the same issue that Didier reported a couple weeks ago? AFAICS, cd ~/scmroot/xemacs-packages hg diff -S DTRTs. I *think* that cd ~/scmroot/xemacs-packages hg diff -S xemacs-packages/{vm,gnus} will also DTRT (eg, if you've got independent un-checked-in changes in calc that shouldn't go into this patch), but it's only lightly tested. Maybe even cd ~/scmroot/xemacs-packages/mule-packages hg diff -S to pick up only changes under mule-packages (but I haven't tested that). Regards, _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

There is an extension, onsub. http://mercurial.selenic.com/wiki/OnsubExtension It's more or less just a way to run a command on all subrepos. So pulling in all subrepos is done like this. hg onsub "hg pull -u" I use it in the package smoketest to ge the latest versions off all subrepos. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

That is IMO just what the smoketest is there for. Testing the latest released consistent version is not a big favor for developers nor the release manager. I hope so. With mercurial you are even better of than with CVS. You can commit your work without pushing until you are really done. If you need backup of your work you could get that through other means than pushing to the main repo. Anyway. This worked rather well with CVS so I think with Mercurial it should only be better. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Yes if you mix up doing a consistent pull with doing a pull on all subrepos. So in that sense onsub might be evil since it makes that error easier to make. Yours -- %% Mats _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: I think you're right and I was wrong: Package authors may want to use the smoketest to find out if their packages builds outside their own environment, and push something there that hasn't gone through Norbert. If that's true (and I think it is), Mats should indeed to an onsub-pull to feed the smoketest. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: I think that it should also be possible to use named branches. The big problem with named branches is that they have a habit of coercing "tip" to themselves, and you end up with everybody that pulls from that repo on a branch that's not related to them. This may have been fixed since I did that.... _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mike Kupfer <mike.kupfer(a)xemacs.org&gt; writes: No. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mike Kupfer writes: No. Aren't we all! Why should you be special? :-) Mike S's proposal is that (1) package maintainers (ie, those allowed to commit to the package) commit and push in the package, but not in the top level. (2) Norbert pulls in the package, then commits and pushes in the top-level, followed by doing what he's always done. Seems reasonable to me. Yes. Maintainers should update AUTHOR_VERSION, as usual. You won't get any argument from me on that. However, people who are used to them might be able to use them to communicate branches via the package repos. It's their package they screw up if they get it wrong. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

* Mike Kupfer <mike.kupfer(a)xemacs.org&gt;: Hi! That's the way I see it, yes. norbert. -- _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Ar an seachtú lá is fiche de mí na Nollaig, scríobh Michael Sperber: I agree with this position. If someone wants a repository of their package where commits don’t provoke the smoketest, it’s easy and reasonable to clone such a repository under one’s own space on bitbucket. -- ‘Iodine deficiency was endemic in parts of the UK until, through what has been described as “an unplanned and accidental public health triumph”, iodine was added to cattle feed to improve milk production in the 1930s.’ (EN Pearce, Lancet, June 2011) _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mike Kupfer writes: The help text in "hg help subrepos" isn't terribly explicit, but if you decode the descriptions of "pull" and "update", it implies that update in the top repo actually does a pull on the subrepos based on the current content of .hgsubstate, then updates them to the specified revision. I'm not sure if the subrepo now contains "future" revisions or if they get "hg strip"'ed. I'm sure it's not! :-) We haven't fully worked out the workflow that gets this done. I suspect that using the hg onsub extension (at least for pull) is a bad idea here. I think it has potential to pollute .hgsubstate. At least in my case I most always have half-baked and/or half-decayed changes in various packages, and it would be embarrassing or worse if they leaked. See also the comment below; it will impose a restriction on package developers that they if they push to the public repo for their package *only* to communicate with other developers (eg, for those of us who use the XEmacs repo as the primary public repo), they risk having half-baked code exposed in releases. (This may be avoided by using named branches instead of the trunk for *all* development, for example, but I do want to point out the need to be careful. I have not confirmed how named branches interact with subrepos, though.) It looks to me like it should go like this: # Package maintainer cd .../package-top hg pull -u # get all *published* changes to # packages recursively cd xemacs-packages/<pkg> hg pull -u # *optional* and useful only if # there are "unpublished" changes # in the public repo xemacs <file1> ... hg commit -m "changed <file1> ..." # look Ma, no push yet! # it may *not* be OK to push here: # that means that people who do # "hg onsub pull -u; hg commit" # will pollute .hgsubstate! cd ../.. hg commit -m "publish sources of <pkg>" xemacs-packages/<pkg> # updates .hgsubstate hg push # recursively pushes I *think* (but haven't tested) that this procedure will capture the changes to <pkg> (that's almost certain), and *only* the single package change to .hgsubstate in the top-level. Now Norbert can do cd .../packages hg pull -u # should get changes to <pkg> and make the distribution package for <pkg> as usual. I don't see a lot of harm in trying various procedures at this point, except that committers *and Norbert* (sorry, Norbert, but ex oficio you're the QA person of last resort here!) should check to see whether their procedure gave sensible results. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Michael Sperber writes: I agree with what you wrote as far as it goes. But is that really responsive to my comment? (N.B. in the comment, "people" should actually read "other people".) OK, but in that case the committer in <pkg> needs to do a push in <pkg> after committing above. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Mats Lidell writes: I doubt that XEmacs has introduced many such keywords, but a lot of upstream projects used them. Also, RMS hates them, so core Emacs people generally avoid them. They mostly show up in 3rd party libraries written by people who have real customers in their day jobs, unlike RMS who needs to please only himself. CVS defaults to expanding them, so upstream can get a pretty good idea of which version users have (of course there may be downstream/user mods). Because it defaults to automatic expansion, we never notice unless upstream complains that we've checked into our CVS and they're getting uninterpretable bug reports with our version numbers, not theirs. The problem when you switch to a different VCS is that the format of expanded keywords changes, breaking regexps etc used to capture the version number. You'll typically get the same kind of bug that Vin observed. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta

Vin Shelton writes: Since you're proposing to do the work, sure. :-) As I wrote to Mats I suspect there may be some VCS fallout if there are upstreams still using CVS, but I'll be happy to help deal with it "if and when". Right, and I think cperl's version extractor regexp would blow up on that, no? "Latest sources" means ours, or upstream? I'm not sure I see the benefit from this. Certainly it would be good for our image and our own morale if both packages and core (mea maxima culpa) got on to regular release schedules, but I don't see the benefit from a one-off effort to re-release right now? _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta