[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-users] Subclipse and Large Projects

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-09-22 18:00:55 CEST

"Marvin D. Toll" <MarvinToll@gtcGroup.com> wrote on 09/22/2006 11:49:32
AM:

> Agreed, conventional wisdom is to *not* trust TaskManager. I'm simply
> trying to get a handle on why our large projects fail to load with the
> plugin; the same project imports without incident using command line
tools (
> c:/>svn import ... ) - so it does *not* appear to be server-side
related.

Share Project is not doing svn import. It is doing an "in-place" import.
Meaning it svn adds everything and then does svn commit. Advantage to
this is that it leaves you with a working copy. You can do an svn import
from the SVN Repositories view. You will need to follow that up with a
checkout.

Regardless, I presume that doing a Share Project of 40K files and 220 MB
is not an every day task. It seems like checking out and working with the
project would be a better test of the plugin.

> I've presumed JavaHL would have greater performability then JavaSVN.
> However, if JavaSVN has greater reliability with a large project perhaps
a
> trade for potential performance is warranted?

I was not suggesting one is better than the other, just how it would
factor into memory usage and your diagnostics. If you were using an
all-Java solution and there was a memory leak, it would show up in the
heap size and allocation. If you are using JavaHL, then there are memory
allocations also happening in the Subversion libraries which would not
show in the Java heap.

> It doesn't seem reasonable that a 46,000 artifact project should cause
so
> much hassle. Is this significantly larger compared to what others are
> doing?

We have no way to know the answer to that. Like I said earlier,
committing 46K items is not likely to be something you, or anyone, do on a
regular basis. We have made performance fixes to help with large
projects, but I do not really know if that takes care of all issues.

> P.S. I must admit your assertion there is no test suite for Subclipse
> caused a "gasp" on this end. We are on the verge of recommending a
switch
> from a (very) mature vendor implemented source control system to
Subversion
> for a Fortune 300 company. Integration with Eclipse is a critical
success
> factor. Is it possible your comment was contextualized - and there is a
> unit test suite invoking plug-in code?

The only unit test suite we have is on the svnClientAdapter layer, which
is the Subversion API. There are no tests for the plugins. Do you know
that your (very) mature vendor has automated test suites, or do you just
assume so because they are a (very) mature vendor? Where would Microsoft
and SourceSafe fit on this scale? I have used commercial plugins, such as
the one for PVCS Version Manager. It would try to get the repository
status of each of your 46K files each time you started Eclipse.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Sep 22 18:02:18 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.