Alex,
Any possibility that it has something to do with the commitAcrossWC
feature that we are using in Subclipse? All commits when using JavaSVN go
through that method and I imagine it adds some overhead as you analyze
what is being committed.
That being said, I would assume that all of the extra work would happen
prior to the commit sending any files to the server.
Mark
"Alexander Kitaev" <alex@tmate.org> wrote on 02/07/2006 07:09:34 AM:
> Thanks for the log Udo,
>
> There is no special delay in JavaSVN of course. The only difference is
that
> JavaSVN tries to reuse the same connection (uses keep-alive http header
flag
> and doesn't close socket after each request).
>
> I will check what other things could cause 15-secs delay, among those
could
> be also TortoiseSVN program - it uses service that caches Subversion
> administrative files and sometimes locks files, forcing JavaSVN to retry
> rename operation for several times, but in general comand line client
should
> suffer from that as well.
>
> Also, if possible, please try JavaSVN 1.0.3 (checkout it from
> http://svn.tmate.org/repos/jsvn/branches/1.0.3/ branch, set env.
variable
> ECLIPSE_HOME so that it points to Eclipse home and use "ant deploy"
command
> to build the library).
_____________________________________________________________________________
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
Received on Tue Feb 7 14:27:09 2006