Re: hg diff --subrepos [was: Bug in cperl-mode.el ...]

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