the bigger problem here is that subclipse update mechanism does stuff
underneath eclipse that it shouldnt really do..
We have problems with that because of the refresh subclipse does because of
that (specific workspace file(s) jobs are completely circumvented because of
we kind of worked around that in our plugins, but it isnt that nice :(
What really should be done is that the svn clients (javahl or svnkit) should
work on an abstract file layer and not directly on files.
This is ofcourse completely impossible with javahl. But it should be
possible with svnkit i think.
What should be done is that svn kit is configured with a interface that
abstract the file io. And then you have 2 implementors of that
the default file io one that is just in the base of svn. But subclipse would
have to implement another one that doesnt work file java.io.File
but with org.eclipse.core.resources.IFile so that all file manipulation
stuff are done through eclipse api. And no refresh triggers need to be done.
On Thu, Jan 8, 2009 at 16:57, Mark Phippard <mphippard_at_collab.net> wrote:
> On Wed, Jan 7, 2009 at 7:28 PM, Tom Walter <tom.walter_at_hitwise.com> wrote:
> > I've done as you suggest and timed it. It seems that a manual refresh on
> > project (with no modified files) takes about 5 mins, which is the same
> > length of time as an svn switch or an svn branch/tag. This remains the
> > whether I run the refresh immediately prior to the svn switch or not.
> > So clearly it is just that eclipse takes a long time to refresh my
> > particular project. I'll see what I can do about that. I suspect it is
> > because it is a large project accessed from windows over a samba
> > to a linux fileserver.
> > I think you've mentioned before that subclipse has to do the full refresh
> > ensure eclipse refreshes the hidden .svn directories. It would be great
> > see an enhancement to subclipse that could trigger eclipse to refresh
> > the files changed by svn (and the hidden .svn directories), without
> > requiring a full project refresh. I think that would provide substantial
> > performance increases for people who develop on remote servers, which is
> > uncommon. As it is, a 5 minute wait after any project level svn process
> > makes subclipse impractical for use in this situation. Can I file a
> > request?
> It would not be difficult to only update the .svn folders but I would
> be skeptical it would make that big of an improvement. We'd still
> have to walk the tree and discover each of these folders and then
> issue the Eclipse API to refresh each of these. It is conceivable
> that the process of walking the tree could trigger Eclipse to see it
> is out of date and refresh anyway, we have certainly run into cases
> like that in the past with certain Eclipse API calls.
> Unfortunately, there are no easy ways to test what kind of difference
> it would make. If you want to setup an environment where you have
> Subclipse checked out and run and test it in an Eclipse runtime, I
> could send you patches to try and see what kind of difference it
> Mark Phippard
Received on 2009-01-08 17:32:44 CET