>>>>I committed all of the files that were selected by default, but the
>>>>problem exists. Is there something else?
>>>I never said the problem didn't exist.
>>>But did you try the CL client with a file containing all the files to
>>>commit too? What was the performance/memory use there?
>>The performance was much better when using svn.exe on the commandline with
>>the -F filelist.txt method. svn.exe took up about 16 MB of memory and 15
>>MB of virtual memory during the "CHECKOUT" process and gradually maxed out
>>at 60MB of memory and 58MB of virtual memory by the final
>>"PUT/MERGE/DELETE". (Compared to 500MB and 1GB with tortoise throughout
>>almost all of the process)
>Do we talk here about a checkout or commit? You said that TSVN uses large
>amounts of memory when doing a commit, and then you try a checkout with the
The CHECKOUT/PUT/MERGE/DELETE are simply refering to entires in the the
access_log that apache generates throughout a commit. They were just
>>>Where exactly does TSVN appear to be doing something? After you click
>>>"ok" but before the progress dialog shows up? Or after the progress
>>>dialog shows up but before something is written there?
>>(after the progress dialog shows up but before something is written there)
>>It looks like this is the approximately the same for both usage methods,
>>so the memory usage is probably a more relevant issue.
>And exactly here's the problem: in the progress dialog, TSVN only calls the
>Subversion API's to do the job. So all memory use you see there and all
>delays come from the Subversion library.
>>There is not a memory problem with the svn commit on the commandline.
>I really doubt that. You just told above you tried it with a checkout. And
>a checkout is something completely different than a commit.
>You have to compare the same commands here.
It wasn't a checkout. It was a commit.
>If you can give me an exact recipe with which the CL client doesn't use
>much memory but TSVN does, *then* I start spending hours of my time to find
>the reason. But as of now, all you've told me points to the Subversion
One way may be to autogenerate 5000 files and put them in a svn repository.
Append a few lines of code to each file and then commit the files to the
repository through tsvn and the svn commandline. The repo that I was using
had 40000 revisions, so that may cause some issues, but it shouldn't.
Express yourself instantly with MSN Messenger! Download today - it's FREE!
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Feb 21 16:54:17 2006