hg diff --subrepos [was: Bug in cperl-mode.el ...]
Stephen J. Turnbull
stephen at xemacs.org
Fri Dec 23 23:31:58 EST 2011
Mike Kupfer writes:
> Jerry James wrote:
> > How about hg pull? I did an hg pull in the top level packages
> > directory, and was told that manifests were updated ... but no actual
> > source files. By looking at the ChangeLog, I found the subdirectories
> > I had to enter to pull the actual file changes. Is there some way of
> > doing a pull on all subrepos? (I can't see one in the help
> > text.)
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.
> It looks to me like the .hgsubstate file in the top-level
> (xemacs-packages) repo is not getting updated properly.
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
hg pull -u # get all *published* changes to
# packages recursively
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!
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
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.
More information about the XEmacs-Beta