In-line below ...
From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-09-22 18:00:55 CEST
MP --> 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.
MDT --> Yes, we have successfully "loaded" the representative large project
using the command line "svn import" followed by a "in this manner.
MP --> 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.
MDT --> "Share Project" was being used as a "benchmark" performance
operation - and to determine how effectively the plugin recovers from a
failure. I'll make an effort to provide performance data from more pedantic
(everyday) operations.
> 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?
MP --> 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.
MDT --> Below is a comparison of using JavaHL vs. JavaSVN.
(Launch with JRE 1.5: C:\programs\eclipse\eclipse.exe -vmargs -Xms256m
-Xmx512m )
*** Using JavaHL ***
Began @ ~17:00
Checked back next morning.
TaskManager of javaw process revealed
Memory usage 1,039,132K / Peak Memory Usage 1,056,572
Error (from console)
Fri Sep 22 01:11:23 EDT 2006
org.tigris.subversion.javahl.ClientException: RA layer request failedsvn:
Commit failed (details follow):
svn: MERGE request failed on '/svn/w2inthelp/trunk/w2int'
svn: MERGE of '/svn/w2inthelp/trunk/w2int': Could not read response body: An
existing connection was forcibly closed by the remote host.
(https://svn.obfuscated.com)
When accessing Eclipse it displayed 86M of 306M heap.
Server du
132396 ./w2inthelp
*** Using JavaSVN ***
Began @ 12:15
Selection List completed @ 12:23 (All artifacts selected.)
Checked back next morning.
TaskManager of javaw process revealed
Memory usage 933,932K / Peak Memory Usage 942,436
Error (from log)
!ENTRY org.eclipse.core.jobs 4 2 2006-09-22 17:38:11.064
!MESSAGE An internal error occurred during: "SVN Commit".
!STACK 0
java.lang.OutOfMemoryError: Java heap space
Could not access Eclipse - Status - "Not Responding"
Server du
160K ./w2inthelp
> Is a [46,000 artifact] significantly larger than what others are
> doing?
MP --> 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.
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?
MDT --> By "mature" it includes being in production handling 20+ years of
Cobol history for an application - and you remember how verbose Cobol was!
(Or, is that memory just mine :-) Your point is well taken - I don't know
if IBM performs either functional and/or load tests; specifically,
client-side performance of the Eclipse plugin.
Suffice it to say, if there is no formal load testing for Subclipse in place
- I'm willing to put together a small test plan and archive the load test
project for subsequent execution of the plan. (Of course I'm more
interested in "typical" operations than the project "load" above.) This
would not be definitive - however, if a particular operation showed 20%
improvement with a new Subclipse release it could be cause for potential
celebration.
_Marvin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Sat Sep 23 16:04:00 2006