On Wed, Sep 17, 2008 at 10:08 AM, Hendrik Maryns
<qwizv9b02_at_sneakemail.com> wrote:
> Hendrik Maryns schreef:
>> Mark Phippard schreef:
>>> On Wed, Sep 17, 2008 at 8:00 AM, Hendrik Maryns
>>> <qwizv9b02_at_sneakemail.com> wrote:
>>>
>>>> I think this time it's a bug in Subclipse:
>>>> I have a link to a pdf file, but only the link under vc. I changed a
>>>> property from the link (non-executable) (but any other change to the
>>>> file will do). Now in the synchronize view, the file is marked with
>>>> outgoing changes and if I click on it, I get a compare view with binary
>>>> garbage on the left and 'link /path/to/file' on the right.
>>>>
>>>> Committing works fine, though: the link is preserved.
>>> There is no possible way to do a valid compare here. All SVN stores
>>> in the repos is link /path/to/file.
>>
>> Indeed. Well it would make some sense to compare the files containing
>> the link information, this is what the command line does:
>>
>>> svn diff
>> Index: kruisend-tiger.pdf
>> ===================================================================
>> --- kruisend-tiger.pdf (revision 423)
>> +++ kruisend-tiger.pdf (working copy)
>> @@ -1 +1 @@
>> -link TI/src/kruisend-tiger.pdf
>> \ No newline at end of file
>> +link ../../Oberseminar TI/src/kruisend-tiger.pdf
>> \ No newline at end of file
>>
>> But that's only useful if the link has changed, not if the file has changed!
>>
>>> Perhaps we should look for the
>>> svn:special property and not allow you to take the option. You can
>>> file an issue
>>
>> Will do: http://subclipse.tigris.org/issues/show_bug.cgi?id=795
>>
>>> or submit a patch for that.
>>
>> Hm, I'm afraid my hacking skills do not suffice for that yet. But most
>> of all my knowledge of the Subclipse code.
>
> I noticed this occurs as well if you change e.g. a property on a binary
> file. In my case the pdf file is compared with itself, since only a
> property has changed. There is no soft link here. And I suppose this
> would also happen if the file really were changed. So Subclipse should
> honor the mime-type property here and not try to do a text compare.
That could be more difficult. The Eclipse compare framework could in
theory have a compare viewer available for the file type. The
architecture supports that. So we'd need to really have a way to ask
Eclipse if it had one before we just aborted.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-09-17 16:36:40 CEST