i just ran into this problem too and i think it is most annoying. F5 just goes so much quicker than fumbling thru those context menues.
i also think that this should be mentioned in a migration guide and added to the FAQ.
if this could be detected automatically via an event it would even be better.
> On Mon, Oct 31, 2011 at 11:34 AM, Chris Feldhacker <
> feldhacker dot chris at principal dot com> wrote:
> > > Next time it happens, try Team > Cleanup
> > > I believe we made that option do a forced decorator refresh in addition
> > to what it normally does.
> > Update: Committing with TortoiseSVN and going back to Eclipse shows the
> > out-dated icons, and the Synchronize View shows out-dated changes.
> > However, per your suggestion, performing a Team > Cleanup DID update the
> > icons and subsequent Synchronize View results display correctly. It would
> > be great if this didn't need to be a manual step that needs to be performed
> > each time...
> > (The structure being used is "WC Root > Project1", where only "Project1"
> > is loaded into Eclipse. I see the structure might matter from other
> > posts...)
> There has to be some kind of "event" that we can hook into that allows us
> to know to refresh the decorators. The problem in your scenario with 1.7
> is that if you do a commit outside of Eclipse then nothing inside your
> working copy changes after the commit. All of the changes happen in the
> metadata folder and that is not part of your Eclipse workspace. So an
> Eclipse refresh does nothing at all and does not trigger any code.
> On the other hand, using 1.6 you had to do an Eclipse refresh, now you do
> not. Instead you have to do Team > Cleanup. Would it be better if we
> named the option to something like Team > Cleanup/Refresh ?
> We are certainly open for ideas if someone can think of a different event
> that Eclipse fires that we can use to trigger this code.
> Mark Phippard
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2011-11-24 14:46:43 CET