Norbert Koch writes:
> What's the output of "hg heads"?
,----[ hg heads ]
| changeset: 898:7970bc3d910c
| user: Aidan Kehoe <kehoea(a)parhasard.net>
| changeset: 897:da9a831ac5eb
| user: Norbert Koch <viteno(a)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
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
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.
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.)
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
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
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.
XEmacs-Beta mailing list