A couple of people from my team here as well as myself have experienced
slowness during checkout if the process is placed in the background instead
of allowing it to run it's course in the foreground. This happened with CVS
as well though. It appeared as though Eclipse was trying to do a build,
cvs/svn update and UI update all at the same time which made everything
considerably slower. Clicking the progress monitory in the lower right
corner does not help.
Eric
On 4/13/06, Mark Phippard <markp@softlanding.com> wrote:
>
> "Andrew Goodnough" <Andrew.Goodnough@wicourts.gov> wrote on 04/13/2006
> 11:42:37 AM:
>
> > We're authenicating to an LDAP server thru Apache WebDAV. Apache and
> > SVN are on the same SUSE Linux box. The CLI is very quick on all
> > operations so we think this is a problem at the Subclipse level.
> > Checking out one of our applications is also slow from Subclipse and
> > takes 11.5 min every time. I've been told it's a large project by SVN
> > standards - 20046 items, totalling 239.5 MB. It also was brought over
> > with 4-5 years of history (branches/tags, everything) from CVS using
> > cvs2svn.
> >
> > Things we've tried to fix it, nothing worked except #3 and we don't
> > want to do that:
> > 1) Turning off indexing of the drive on Windows clients
> > 2) Switching the Subclipse preferences to use JavaHL instead of
> > JavaSVN.
> > 3) Using SSH (we don't really want to lose the LDAP auth, though)
> > 4) Looking through the Subclipse code. I noticed that most of the core
> > methods in the JavaSVN code (checkout, update) are synchronized. My
> > theory was that it was the synchronized Java wrapper around the "fast" C
> > libraries that was slowing things down. But, if this is true, using the
> > JavaHL setting should have bypassed these methods and made them faster,
> > which it didn't.
> >
> > Thanks in advance for any ideas.
>
> I would guess that the Eclipse build and Subclipse status crawl would add
> a lot to the slowness. An SVN command line checkout does not do either of
> these. The console view should reflect this as you should be able to see
> when the checkout stops.
>
> All that being said, an SSH checkout would have to do all of this too.
> There is no question that http:// is slower than svn:// and svn+ssh://.
> Besides the protocol being a lot slower, it has to Base-64 encode all of
> the data and the Working copy also contains a lot of extra files that do
> not exist when using another access method. So you pay a penalty in
> several areas.
>
> We stopped using synchronized client adapter around the 0.9.100 release,
> but I doubt that slowed stuff down too much.
>
> Mark
>
>
>
> _____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
> Email Security Management Services powered by MessageLabs.
>
> _____________________________________________________________________________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>
--
Infinite Loop: Someone included an include that included the include?
Received on Thu Apr 13 18:09:57 2006