problem: fail to apply the patch [continue]

chen.xi at telecom-bretagne.eu chen.xi at telecom-bretagne.eu
Wed Dec 14 13:48:25 PST 2011


Yeah, I solved the problem. As some of you have mentioned, the status  
file is not clean, because I occasionally did some "out-of-band" strip  
and confused the mq.

Thanks a lot.

-- Chen

John Rose <john.r.rose at oracle.com> a écrit :

> On Dec 13, 2011, at 5:24 PM, chen.xi at telecom-bretagne.eu wrote:
>
>> The Openjdk I fclone is hsx/hotspot-comp. I just followed the
>> instruction on mlvm wiki.
>>
>> I tried the strip command as you said. But it did not help any more.
>> E.g., the hotspot patch requires revision is "d8cb48376797". Its first
>> descendant is "cec1757a0134". So I do "hg strip cec1757a0134" in
>> order to remove all the changeset before "d8cb48376797". But this
>> command failed. Output message is:
>> ------------------
>> mq status file refers to unknown node 4c9ea0147722
>> mq status file refers to unknown node daf841a4cc84
>> abort: unknown revision 'qtip'!
>> ------------------
>>
>> As showed above, message like "unknown node XXXX" appears again.
>> What's more, how does Mercurial know the revision 'qtip'? I searched all
>> the tags and there is no qtip.
>>
>> So let's simplify my problem. We just focus the error at the very
>> beginning. Let's only do qpop for all the source repo.
>
> With problems like this, the quickest way out is to delete the whole  
> repo and pull a fresh copy.
>
> Note that mq uses the "strip" command internally to push and pop  
> versions.  It uses the status file to keep track of where it is.   
> Therefore, if you do an "out of band" unexpected "strip", mq will no  
> longer be able to track what's pushed.  That is the reason for some  
> of the errors.  But it's not worth debugging.  Do an "hg diff" to  
> save any uncommitted differences, move your dead repo. to a holding  
> folder (or delete it if you feel lucky) and make a new one.
>
> I hope this helps!
>
> Also, I have rebased the 292-related patches, so there will be less  
> chance of confusion with patch mismatches.  As people may have  
> noticed, I do this about once a month, but missed November.
>
> -- John
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
>
>





More information about the mlvm-dev mailing list