problem with extdiff extension
James Walker
kagi at jwwalker.com
Tue Aug 23 07:14:51 UTC 2011
On 8/22/11 10:33 AM, Mads Kiilerich wrote:
> On 08/22/2011 07:16 PM, James Walker wrote:
>> On 8/22/11 9:58 AM, Mads Kiilerich wrote:
>>> On 08/22/2011 06:25 PM, James Walker wrote:
>>>> The extdiff extension is not working for me lately, depending on which
>>>> arguments I pass. I'm using hg version 1.9.1 on Mac OS X 10.6.8. My
>>>> .hgrc enables extdiff and then configures it as follows:
>>>>
>>>> [extdiff]
>>>> cmd.bbdiff=/usr/bin/bbdiff
>>>> opts.bbdiff=--wait --resume --reverse
>>>>
>>>> Here bbdiff is a command that invokes the BBEdit text editor.
>>>>
>>>> If I say
>>>>
>>>> hg bbdiff Source/StatusController.mm
>>>>
>>>> then it works correctly. If I say
>>>>
>>>> hg bbdiff -r 53 Source/StatusController.mm
>>>>
>>>> then I get
>>>>
>>>> bbdiff: error: -36
>>>>
>>>> where -36 is a Mac OS code that means I/O error. And if I say
>>>>
>>>> hg bbdiff -r 53 -r 56 Source/StatusController.mm
>>>>
>>>> then there is no response at all.
>>>>
>>>> I suppose there could be a bug in bbdiff or BBEdit, which have been
>>>> updated about as recently as Mercurial, but I'm not sure how bbdiff
>>>> could tell the difference between these 3 cases. In each case, it
>>>> should
>>>> just be receiving 2 files.
>>>>
>>>> Any suggestions on how to proceed?
>>>
>>> Try to add
>>> --debug --traceback
>>> when you run hg and see if that gives a hint.
>>
>> OK, thanks...
>>
>> hg --debug --traceback bbdiff -r 53 -r 56 Source/StatusController.mm
>>
>> still produces no output at all, but
>>
>> hg --debug --traceback bbdiff -r 53 Source/StatusController.mm
>>
>> produces:
>>
>> making snapshot of 0 files from rev 55eb4c5075e3
>> running "'/usr/bin/bbdiff' --wait --resume --reverse '/dev/null'
>> '/Volumes/Work2/mercurial/MacMerc/Source/StatusController.mm'" in
>> /var/folders/vF/vFOjdRypG88ctSvpPVHqlU+++TI/-Tmp-/extdiff.1TtmZb
>> bbdiff: error: -36
>> cleaning up temp directory
>>
>> Aha, apparently the file got renamed into a different directory in
>> revision 102, so it's not being found in revisions 53 and 56.
>
> Are you sure this problem is related to upgrading Mercurial?
Not at all. It is certainly possible that this is the first time I ever
tried doing a diff of a file that had been moved, using a revision from
before the move.
> Anyway, feel free to file it in the bugtracker - with an example of how
> it can be reproduced.
Maybe it's more of a feature request, that Mercurial do a better job of
tracking files through moves and renames.
Or failing that, I wish I knew some way to take a current pathname and a
revision, and ask Mercurial: What was the pathname, if any, of this file
at that revision?
More information about the Mercurial
mailing list