workflow help

[Chuck Kirschman]

I'd like to set up a workflow like this for a relatively large, very active group:

1.  User A creates changesets A1 and A2.
2.  A1 and A2 are submitted to the server, which puts them in a queue (probably via bundles). Changesets from other users B and C are ahead in the queue.
3.  Each changeset (B then C then A1/A2) is rebased into the main branch automatically, built, and then accepted into the trunk (or rejected).
4.  The codebase is very large so builds take a long time. In the meantime A3 and A4 are generated by User A, who pulls B' and (preferably) rebases or merges.
5.  The next day, User A does a pull and gets C', and the new A1'/A2' without getting duplicates. A3 and A4 move to the tip of the trunk as development continues.

Step 5 is the one that has me the most stymied. I just need some way for a developer to be able to pull the trunk and not have to do manual fix-up of their tree to get their changesets in order (there are dozens of repositories). I also need some explainable workflow as to how to recover if your changeset is rejected. Does anyone have experience with this type of workflow that can recommend a tactic?

The only documentation I can find describes how a "git pull --rebase" seems to recognize that the changesets are the same and so A1/A2 disappear whereas with Hg it is a conflict. I don't expect Hg to be exactly the same workflow of course. I have experimented with the evolve extension and having obsolescence markers move into the main tree, but step 4 makes it not work. Pulling in new changesets with rebase means the revisions won't be obsoleted by the markers, and with a merge means that there's a merge revision that if I try to evolve it then it becomes a new tip with unwanted changes.

Any help appreciated.

Thanks
Chuck

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial/attachments/20170606/9d145b65/attachment.html>