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

Pierre-Yves David pierre-yves.david at ens-lyon.org
Tue Mar 25 17:38:42 CDT 2014



On 03/25/2014 03:29 PM, Angel Ezquerra wrote:
> 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.

Please update the bug with the content of the first email. I wont look 
at it right now, and I wont find this email anymore in a few week.

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

Yes, you are :-(

>> 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?

In you original email the trace show

% hg evolve
move:[21] Add the list of mercurial tags to the TFS commit message.
atop:[21] Add the list of mercurial tags to the TFS commit message.

This is VERY WRONG, I'm dunno why evolve think it is a good idea, but 
there is no case where this would ever be a good idea. detection when 
evolev is about to do it and bail out before it does it wrong would be 
simple and effective.


>
>> (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.

I think its already a better alternative to MQ if you are ok with 
unfrozen UI. The bug you encouter is not supposed to be part of the 
early experience (but not totally rulled out).

>
>>> 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).

Yes, you failure is really bad. I would like to at least fail in more 
recoverable manner.


> 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.

hg prune

> This may just be because evolve is still immature. Maybe I am facing
> problems that will never happen when the extension is finished.

evolve is still immature, beta tester must be ready to call for help. 
That what you are doing an this is good.

> 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 :->

no evolve is failing is a very bad an confusing way.

>
>> (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?

Keep it around, I'll ask it to you when I'll look at that bug (or 
consider uploading a PGP encrypted tarball to the bug report)

and please update the bug report

> 2) I really do not think I have the understanding necessary to write
> those 3 lines :-P

Are you able to compare two integers in python to see if they are equals?

If so, you are qualified to provide a fix

If not, I wonder how you figured out which way of the keyboard goes up ;-)

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list