Hi,
We found a problem when committing a huge revision (2**18+1 = 262145)
of one single file to a repository.
OS:
Client: Windows XP Prof SP2
Server: Windows Server 2003 SP1, total physical memory: 4 GB
Subversion:
Clients: svn, tortoisesvn
Version: 1.3.2, 1.4.2, 1.4.3
Fs-type: FSFS
Format: 3 (pre-1.4), 5 (1.4)
Protocol: file://, https://
The test case is a loop with echoing the revision number to a file
and then committing it, e.g. in a Windows command line:
> for /l %i in (1,1,262145) do (echo %i >f && svn ci -m"%i" f)
We observed that the commit of the first revision after 2 to the power
of n lasts longer than the other ones:
revision duration [sec]
2**12+1 2
2**13+1 14
2**14+1 36
2**15+1 84
2**16+1 190
2**17+1 316
2**18+1 commit aborted
For the last commit (2**18+1) we got the following error messages:
file://
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
https://
svn: Commit failed (details follow):
svn: OPTIONS request failed on '/<location>/<repo>'
svn: OPTIONS of '/<location>/<repo>': SSL negotiation failed: Secure connection truncated (https://<server>)
We assume that it is a memory issue in FSFS: During the commit the
process permanently increases the memory until no memory is left and the
process aborts. Servers with less memory (1 GB) shows this behavior for
lower revisions, e.g. 2**17+1 (131073). The problem doesn't occur on BDB.
George
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue May 22 16:31:32 2007