Ok - either refreshing the 'src' folder (or getting the file properties) has
caused eclipse to now acknowledge that the file has, indeed, changed (in
that it will now show that there are changes, and it appears as an outgoing
change in synchronize).
However, the decorators are still showing as an unchanged icon, and at r3430
(svn info on the commandline reports 3431) - I'm less bothered by that as
labels may be lazy (though repeated refreshing the file seems to make no
difference).
So I'd say there's definitely a bug in the eclipse refresh behavour, since
refreshing the project didn't do something that refreshing a directory did.
And the file on disk isn't even the same size as the file that was in the
repository - I can't believe any refresh-on-invalid validity check would
miss that!
> > One other thing I've noticed is that in the package explorer, the file
> is
> > listed at revision 3430, but in the properties dialog (subversion
> section),
> > it lists the revision as 3431... could this have anything to do with the
> > problem?
>
> It is just more of the same symptoms. The decorators get refreshed
> when Eclipse asks for new values. It does that when it thinks
> something has changed.
>
> When you run Refresh, Eclipse only refreshes stuff that it thinks has
> changed. So somehow, Eclipse thinks it has the latest of this file.
> That is why I suggest you force a refresh by editing the file.
>
> In terms of reporting the bug, the problem is that the bug is not in
> the Refresh, it is in whatever the root cause that triggered this was.
> That will be hard to determine.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
Received on Fri Jul 27 15:31:29 2007