workflow help

[Chuck Kirschman]

On 06/06/17 15:16, Chuck Kirschman wrote:

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

I really thought that an automated accept/reject scheme would not be something new at this point. Maybe I'm asking the wrong question? Here's a script that I thought might work, but it fails on the last step because it tries to merge (duplicate) the pushed changesets. Is there some other workflow I should be using?

Thanks
Chuck

# Simulate multiple users working on the same repository with automated acceptance scheme.
rm -rf master
rm -rf build
rm -rf c1
rm -rf c2
rm -rf c3
rm -rf bundles

# Master repository
mkdir master
hg init master
echo x >> master/m1.txt
hg -R master add master/m1.txt
hg -R master commit master/m1.txt -m"m-1"
echo x >> master/m1.txt
hg -R master commit master/m1.txt -m"m-2"
echo x >> master/m1.txt
hg -R master commit master/m1.txt -m"m-3"

# Build repository
hg clone master build

# Setup first client
hg clone master c1
echo x >> c1/client1.txt
hg -R c1 add c1/client1.txt
hg -R c1 commit c1/client1.txt -m"c1-1"
echo x >> c1/client1.txt
hg -R c1 commit c1/client1.txt -m"c1-2"

# Setup second client
hg clone master c2
echo x >> c2/client2.txt
hg -R c2 add c2/client2.txt
hg -R c2 commit c2/client2.txt -m"c2-1"
echo x >> c2/client2.txt
hg -R c2 commit c2/client2.txt -m"c2-2"

# Setup third client
hg clone master c3
echo x >> c3/client3.txt
hg -R c3 add c3/client3.txt
hg -R c3 commit c3/client3.txt -m"c3-1"
echo x >> c3/client3.txt
hg -R c3 commit c3/client3.txt -m"c3-2"

# Create the 3 bundles simulating the queue; all clients have pushed
# Hopefully this is done with a push hook
# All changesets are still draft phase
mkdir bundles
hg -R c2 bundle bundles/c2.bundle
hg -R c3 bundle bundles/c3.bundle
hg -R c1 bundle bundles/c1.bundle

# Process first bundle
hg -R build pull bundles/c2.bundle --rebase
hg -R build update
hg -R build push master

# Client 1 pulls at this point
hg -R c1 pull master -u --rebase

# Process second and third bundle
hg -R build pull bundles/c3.bundle
hg -R build rebase -b 5 -d 4
hg -R build pull bundles/c1.bundle
hg -R build rebase -b 7 -d 6
hg -R build push master

# Client 1 pulls again, getting the changesets that were pushed
hg -R c1 pull master -u --rebase

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20170609/1a6df74d/attachment-0002.html>