news <news@sea.gmane.org> wrote on 07/30/2006 06:11:02 AM:
> Mark Phippard wrote:
>
> >>
http://subclipse.tigris.org/servlets/ReadMsg?listName=users&msgNo=5722
> >>
> >> is there a solution for this problem?
> >
> > Subclipse 1.0.3/1.1.2 included a fix when JavaSVN was the adapter.
JavaHL
> > did not have a problem.
>
> This sounds as if the problem has been fixed. I'm afraid this is not the
> case, for Subclipse 1.1.4 (JavaSVN). I am using Eclipse 3.2 (Callisto),
> svn 1.3.1 client-side (Ubuntu Breezy) and svn 1.1.4 server-side (Debian
> Sarge).
Can you try it with JavaHL? Can you try going back to the 1.1.2 release.
I know what we "fixed" worked correctly in 1.1.2, it is possible there has
been a regression.
> > If you are updating a lot of files outside of Eclipse there is going
to be
> > some price to be paid once Eclipse sends out the change notifications
on
> > all of those files.
>
> I don't understand why Subclipse does that for directories that should
> be ignored. Is this intentional?
How do you expect Subclipse to know that these items are ignored? The
work that you are seeing is the process of discovering that information.
When the files are built by Eclipse they are marked as "derived" in
Eclipse which allows us to short-circuit all of these checks.
> > In general, it should not be that bad.
>
> Unfortunately, it is. It takes hours to go through the target directory
> of a big Maven build.
It shouldn't take hours. The problem must be back, I'll look into it. You
can verify by using JavaHL, which you can get right from Ubuntu. The
problem was that JavaSVN was reporting that the file was unversioned
slightly differently than JavaHL and this was causing us to not cache the
results, which causes us to issue exponentially more status checks than if
the cache is working.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Sun Jul 30 15:25:24 2006