Re: Need help for a hg push

Norbert Koch writes: :-) 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. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://lists.xemacs.org/mailman/listinfo/xemacs-beta