[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] Re: Text compare does not work properly for linked resources

From: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 17 Sep 2008 10:36:31 -0400

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.

Mark Phippard
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

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.