hg evolve fails with "no support for evolution merge changes yet" error on a linear repository

Angel Ezquerra ezquerra at gmail.com
Tue Mar 25 17:29:13 CDT 2014


On Tue, Mar 25, 2014 at 12:03 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 03/25/2014 03:08 AM, Angel Ezquerra wrote:
>>
>> On Tue, Mar 25, 2014 at 10:45 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>>
>>>
>>>
>>> On 03/25/2014 02:22 AM, Angel Ezquerra wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> I wanted to post this to the new evolve-testers mailing list, but I'm
>>>> still waiting for my subscription to be approved. I hope it is OK to
>>>> post this here.
>>>>
>>>> I'm using the latest stable revision of the mutable-history repository
>>>> (revision 6a67606e1c34).
>>>>
>>>> I often get the "no support for evolution merge changes yet" error
>>>> when I try to use any advanced feature of the evolution extension. In
>>>> particular when I use evolve.
>>>>
>>>> For example I just used fold on a completely linear repository. The
>>>> repository contains a single file. It had 11 revisions on a single
>>>> topological branch. The repository had a few hidden revisions which
>>>> were the result of using amend a few times. I wanted to fold the first
>>>> 7 non hidden revisions In this repository, I did:
>>>
>>>
>>> Is this:
>>>
>>> https://bitbucket.org/marmoute/mutable-history/issue/35/abort-no-support-for-evolution-merge
>>> ?
>>
>>
>> Yes. The main difference is that the repository in which this happened
>> ins much simpler and completely linear
>
>
> So, new data, more chance to build a repro. Cool, can you update the bug?
> (in a concise manner if possible) ?

I don't think there is much to say other than what I said here. What I
can do, if you want, is send you a copy of the original repo where the
problem happens. I'd rather not share it publicly because it has a lot
of temporary revisions in it (that is why I was using fold in the
first place!) but I would be OK with sharing with you.

>> (also I believe that at the
>> time you suggested that we should discuss these things in the
>> mercurial-devel mailing list?).
>
> Yes public discussion is better.
>
>> As I said on my previous email, it worries me a bit that we are
>> suggesting people to use evolve now when it is still quite easy to
>> encounter these sorts of problems.
>
> This bug is very rare. You happen to meet it more than every body else.

I am quite unlucky then! Pretty much every time I've used the evolve
command I've hit some problem :-/

> Until we provide a proper fix for it, we could consider a simple patches
> that prevent evolve to try to evolve a changeset above itself. This would
> limit the consequence of the issue.

Quite frankly I don't really know what "evolve a changeset above
itself" means. Is that the problem here?

> (and note that I'm suggesting people to use evolve with big flashy warning
> all along the way)

Yes, I don't think you have claimed that evolve is perfect or done and
I understand that you'd want evolve to get more exposure and more
testing. However I don't know if it is reliable enough to be proposed
as an MQ alternative yet.

>> MQ is complex, and has many limitations, but it is quite reliable in my
>> experience.
>
> On my experience I had less troubles with people using evolve than with
> people using MQ.

The thing is that with MQ, when it fails it usually just fails to
apply a patch or something like that. It is annoying, sure, but you
rerelly feel that the repo is in a state that is hard to understand.
Patches are either applied or they are not. Maybe I have so much
experience with it that it feels natural to me now. On the other hand,
when using evolve if everything goes fine it is awesome. It even feels
a bit like magic. However, when it fails... it fails hard. I usually
have no clue what is going on after evolve fails on me or what I must
do to fix the problem. The repo gets into a state that I just don't
understand and I don't know how to fix (that is way I always make sure
to backup my repos before doing any advance evolve operation).

For example, when I had this problem today I tried stripping the
evolved revisions, since I could see that the original revisions were
there. But when I did suddenly my repo was empty! All revisions were
gone! The reason was that all the original revisions were hidden. It
is hard to unhide a revision once it is hidden.

This may just be because evolve is still immature. Maybe I am facing
problems that will never happen when the extension is finished.
Perhaps I just don't have the right mental model and I don't
understand what the extension is doing the way I understand the rest
of mercurial. But when evolve tells me that it cannot evolve a merge
changeset on a linear repo... I just don't understand what is going on
and I sort of wish I had used MQ instead :->

> (conclusion, (1) please update the bug (2) consider sending the 3 line
> patches that prevent evolve to have source == destination)

1) As I said, would it be useful to you if I sent you a copy of the
repo where this happens?
2) I really do not think I have the understanding necessary to write
those 3 lines :-P

Angel


More information about the Mercurial-devel mailing list