Need help for a hg push

Stephen J. Turnbull stephen at xemacs.org
Thu Oct 20 06:29:05 EDT 2011


Norbert Koch writes:

 > > What's the output of "hg heads"?
 > 
 > ,----[ hg heads ]
 > | changeset:   898:7970bc3d910c
 > | user:        Aidan Kehoe <kehoea at parhasard.net>

:-)

 > | changeset:   897:da9a831ac5eb
 > | user:        Norbert Koch <viteno at xemacs.org>
 > | date:        Tue Oct 18 21:58:25 2011 +0200
 > | summary:     XEmacs Package Release cc-mode
 > `----
 > 
 > I'm getting confused.  I'm pretty sure I've pulled and updated
 > everything before I made my changes, simply because I don't want - and
 > normally need - to merge.  As Steve has already noted, I'm reacting on
 > input from the developers.

Well, I don't know how Aidan's commit got there (I suspect he put it
there; if so, it looks to me like he should not have done so), and it
seems to be null.  "hg diff -S -c 7970bc3d910c" produces no output.  I
think $PKGROOT/.hgsubstate did not get updated; I don't understand why
not.

According to "hg help subrepo":

    Thus, updating subrepos is a manual process. Simply check out
    target subrepo at the desired revision, test in the top-level
    repo, then commit in the parent repository to record the new
    combination.

So Norbert needs to pull *in* the subrepo (pull does *not* recurse
into subrepos by design, there isn't even an option to do so).

Note that updating .hgsubstate (at least for now) should be Norbert's
responsibility, I think.  That implies that pushes, and maybe commits,
in the top directory, xemacs-packages, and mule-packages should only
be done by Norbert.  Otherwise, Norbert will get updates in subrepos
that he isn't ready to deal with yet.

The workflow I have in mind is as follows.  In all cases each person
doing commits and pushes is doing so on their local host; the
perspective is never from bitbucket, always local.

Package maintainer:

1.  Commit and push in package, and notify Norbert.  (Notification may
    be implicit in the commit mail that's automatically sent -- that's
    up to Norbert.)

Norbert:

2.  cd to xemacs-packages/cc-mode and hg pull -u.  There should be no
    weirdness (conflicts, new heads), if there is it needs to be
    worked out with the package committer.
3.  Update Makefile VERSION and ChangeLog, and commit.
4.  (Don't know if this is the best idea, but it's current practice.)
    Tag with package version marker.
5.  cd to `../..'.  DO NOT hg update (this will revert the changed
    package)!
6.  Update toplevel ChangeLog if necessary.
7.  hg commit.  (This should update the subrepos, see below.)  I think
    you should be able to check with "hg diff -S" in the top directory.
8.  Tag (I don't think we do this now, but I wonder if it's not a good
    idea).
9.  Make new packages and upload them.  Announce availability.

There may be other workflows that work, but I suspect that we really
don't want anybody but Norbert committing in the top, xemacs-packages,
and mule-packages directories.



More information about the XEmacs-Beta mailing list