First, incomplete, but promising stab at converting pbranch scenarios to "changeset evolution"

[Pierre-Yves David]

On 26 août 2011, at 17:41, Peter Arrenbrecht wrote:

> On Thu, Jul 14, 2011 at 2:38 PM, Peter Arrenbrecht
> <peter.arrenbrecht at gmail.com> wrote:
>> "Changeset evolution" is Pierre-Yves David's (marmoute on IRC) take on
>> how we might finally be able to unify mq and pbranch, and get a sane
>> environment for evolving changesets over time (for instance, in a
>> review-feedback cycle, or just while polishing them ourselves). I
>> promised at the last sprint to write it up. My approach is to take the
>> extensive pbranch tutorial and convert it to one for evolution. Here's
>> the first step in this direction:
>> 
>>  http://arrenbrecht.ch/mercurial/evolution/
>> 
>> I believe it shows a lot of promise, and I equally believe converting
>> more of my tutorials will uncover further need for thought. I shall be
>> picking this up again after my 5 week vacation, unless someone beats
>> me to it.
>> 
>> The repo with the tutorial source is here:
>> 
>>  https://bitbucket.org/parren/hg-evolution-tutorial
>> 
>> Feel free to convert this to any other suitable format (hg .t files
>> come to mind, or Brodie's version of it) to continue.
> 
> A quick update. I have implemented some of my vision for evolution and
> pushed it. It's now converted to ReST and run-tests.py, so it's
> runnable by you guys. Idan meanwhile explored some more complicated
> scenarios, which led us to reconsider the approach (transcript below).
> Maybe a hybrid between pbranch and evolution would be better. The
> patch branches would be hidden and maintained by evolution. Users
> would mainly operate on consecutive versions of the final patches,
> much as in the original evolution.
> 
> Cheers,
> -parren
> 
> 
> Transcript:
> 
> idank: parren: I've been messing around with this test
> http://paste.pocoo.org/show/464860/
> idank: it looks like there are several things we can do, not sure what's right
> idank: basically the end result needs to be a merge of 3 and 5 which
> will be a new version of patchA
> idank: (we can't merge 6 and 4)
> parren: idank: Heh, that's what I'm thinking about.
> parren: So merging 4 and 6 is going to conflict on a, which merging 3
> and 5 will not, is that it?
> idank: yeah, that's what happened when I tried that
> parren: idank: This is annoying. It's going to get rather complicated
> when both do multiple amends before we merge.
> idank: both as in someone and a collaborator?

In such case we need merge plumbery to performe a merge between the two conflicting changeset (4 and 6) using their *evolution* common ancestor (1) as base. I'm not sure how this is complicated.

-- 
Pierre-Yves David