news <news@sea.gmane.org> wrote on 08/04/2006 03:20:24 PM:
> Hi Mark,
>
> >> 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?
>
> JavaHL exposes the same problem for me.
>
> > Can you try going back to the 1.1.2 release.
>
> Should I still try?
No, because of that second email I sent where I verified there was no
regression.
> >> 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.
>
> Being naive, I would expect for subclipse to store that information in
> the working copy. Getting it from there would save a lot of network
> roundtrips.
We are getting it from the working copy. We are not doing server
roundtrips on these files, at least not in my tests.
> > When the files are built by Eclipse they are marked as "derived" in
> > Eclipse which allows us to short-circuit all of these checks.
>
> Yes, this is a problem of Eclipse in conjunction of Maven. As Maven does
> not know about the Eclipse internals, it cannot set the "derived"
> property for all files it creates. The only part of Maven that is
> Eclipse-specific (maven-eclipse-plugin) could only set a property on the
> target directory as whole (if at all). Unfortunately, Eclipse only
> supports the "derived" property on a per-file basis, not by inheritance
> from directories.
>
> >> Unfortunately, it is. It takes hours to go through the target
directory
> >> of a big Maven build.
> >
> > It shouldn't take hours.
>
> Well, I was exaggerating a bit... (-: Of course it depends on network
> latency and project size. In any case, it takes about 30 Minutes for a
> synchronize to finish in my project with over 1000 files.
It shouldn't be hitting the network for these files. Have you sniffed
network traffic where you know that it is doing it? Have you tried
Refreshing your project before doing a Synchronize? That might take a
while as that is where we should discover these files are ignored. Then
Synchronize should run reasonably normal. I am mainly trying to figure
out if there are alternate scenarios that I have not run into my
testing/fixing. When I do this, I see Eclipse discover all of these new
files, which triggers us to refresh our cache based on the local working
copy information, and then Synchronize runs with a single svn status -u
call.
We are looking at ways to figure out the files are ignored more quickly
that doesn't hurt the performance for finding out the status of files that
are not ignored.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Aug 4 21:30:32 2006