Amending non-tip changesets
Colin Caughie
c.caughie at gmail.com
Fri Apr 11 17:15:22 UTC 2014
On 4/11/2014 10:00 AM, Colin Caughie wrote:
> On 4/11/2014 8:00 AM, Pierre-Yves David wrote:
>>
>> On 04/11/2014 07:58 AM, Colin Caughie wrote:
>>> I've recently started using the evolve extension as part of my daily
>>> workflow, replacing mq. So far my experience has been excellent; it
>>> seems to work very well and wasn't hard to pick up. I really like
>>> knowing that if I mess up I can always get back to where I was (even
>>> if it still sometimes takes a bit of thinking to figure out how).
>>>
>>> There is one part of my workflow that I haven't quite figured out
>>> how to optimize yet, I wonder if any of you have any suggestions. It
>>> relates to our code review process, which I discussed last month on
>>> the Mercurial list (the "ReviewBoard and Mercurial" discussion). Our
>>> mq-based process goes like this:
>>>
>>> 1. Commit changes as an mq patch
>>> 2. Post a review
>>> 3. Continue working, creating new mq patches as necessary
>>> 4. When you get review feedback, pop the later patches, make the
>>> required changes to the patch under review and qrefresh
>>> 5. Post a diff update based on the amended patch, e.g. using "hg
>>> postreview -e"
>>> etc.
>>> 6. qpush the later patches and continue working
>>>
>>> Steps 4-6 are the interesting ones. I know I can do:
>>>
>>> 4. After feedback, "hg update" to the the changeset that needs
>>> modified, make the required changes and run "hg amend"
>>> 5. Post a diff update based on the amended patch
>>> 6. Rebase the newer changesets using "hg rebase <rev>", where <rev>
>>> is the first changeset after the one being amended
>>> 7. "hg update" to get back to tip.
>>>
>>> This works, but it would be nice to be able to do that
>>> "automatically", i.e. without having to find the revision number of
>>> the changeset to be rebased. Like maybe an "hg rebase --unstable"
>>> option?
>>>
>>> I did try "hg evolve -a" but that did something a bit weird; it
>>> looked like it *merged* the unstable changesets with my amended one
>>> which made the graph look a lot more complicated than it needed to be.
>>
>> hg evolve is exactly meant for that. Can you elaborate on this merge
>> thing? The result should have been the same as rebase.
>
> Been doing some more testing. I updated to the latest version of the
> evolve extension (previously was on 6a67606e1c34 from March 2) and
> tried on both Linux and Windows (previously just using Windows). I'm
> using Mercurial 2.9.1. on both systems, and also tried with 2.9.2 on
> Windows.
>
> On Linux it worked perfectly; "hg evolve -a" rebased all my unstable
> changesets. ("hg evolve" on its own only transplanted the first one to
> the top of my history which I found slightly counter-intuitive but
> acceptable).
>
> On Windows something seems to be going wrong, even though I've made
> sure I'm using the same versions of both mercurial and the extension.
> I start out with:
>
[snip]
> Note that when I was still using the March 2 version of evolve I got
> the same resulting graph but it didn't output the abort message that
> it does now.
>
> I've attached the test script I used to run this scenario. Any advice
> for getting it to work on Windows would be welcome!
>
> Thanks,
> Colin
>
I just found this:
https://bitbucket.org/marmoute/mutable-history/issue/35/abort-no-support-for-evolution-merge
Looks like it's related. I'll add a comment and attach my script in the
hope that someone can reproduce it this way.
More information about the Evolve-testers
mailing list