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

[Pierre-Yves David]

On 03/25/2014 04:08 PM, Angel Ezquerra wrote:
> On Tue, Mar 25, 2014 at 11:38 PM, Pierre-Yves David
> <pierre-yves.david at ens-lyon.org> wrote:
>>
>>
>> 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:
>>> 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
>
> How would that help? Wouldn't that just mark the evolved revisions
> obsolete? The revisions that obsoleted my original revisions would
> become obsolete... and the original revisions would become doubly
> obsolete? Just thinking about it is making my head hurt. I think I'll
> just keep making backups until this is fixed, thank you very much! ;->
>
> What I really wanted was to "unobsolete" the original revisions. I
> think there is hg touch but that creates new revisions (with their own
> hashes) doesn't it?

I mean `hg touch`, sorry, short night.


>>> 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 ;-)
>
> LOL. I may look into this if I find some time. Were should patches be sent to?
>
> Should I just add an assertion that the orig and target revisions are
> not the same? Or would you prefer to raise an exception?

Abort noisely but cleanly

-- 
Pierre-Yves