workflow help

[Pierre-Yves David]

On 06/06/2017 09:15 PM, 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.

The changeset evolution concept is supposed to help here. However The 
evolve extension is an ongoing implementation of that concept with some 
unfinished parts. From what I understand, you've tried the evolve 
extension but still encountered issue.

As you pointed Step 4 is the one that is currently problematic. Your 
initial A1 changesets get rebased in two different repositories:

   - in the automatic acceptance repo as A' (eg: new parent B)
   - in the developer repository as A'' (eg: new parent C)

This creates "divergence" (both A' and A'' claims to be the new version 
of A). Divergence is not an area very polished yet, but we could look 
into what is needed for fit you needs. I've not put too much though into 
this yet, but I can see three missing pieces to make your workflow smooth:

1) rebase should refuse to rebase A' on A'' (by default) since they are 
both divergent,

2) hg evolve should be able to automatically solve the divergence

3) you likely wants a flag to trigger all this on pull.

What do you think? Did I get your work flow right?

Cheers,

-- 
Pierre-Yves David