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

Memory comsumption of svn

From: Ollivier Robert <roberto_at_eurocontrol.fr>
Date: 2002-02-28 11:49:52 CET

[ I'm not on the list so please Cc: me of any answer ]

Hello everybody,

Some background: I'm a FreeBSD developper (so I have a fairly good
experience of CVS) and a Perforce user. I'm currently looking at subversion
because I find it very interesting as a replacement for CVS.

I'm currently testing

Subversion Client, version 0.9.0 (rc2)
   compiled Feb 26 2002, 16:05:54

and I have 1. a problem that was already talked about here and 2. some

I tried to import a FreeBSD a checkout tree of /usr/src (around 380 MB and
lots of files). It aborted after importing about 110 MB worth of files
becuase it hit the datasize limit here (512 MB) and promptly dumped core
(backtrace at the end).

It was also becoming quite slow at the end of the import (which didn't

Everything seems to be in Berkeley db4 files including the files
themselves, not only the metadata right ? Have you any concern about the
size of a repository (I'm even thinking of Linux users on Wintel with their
2 GB limit on files -- or has it been removed yet?) ?

One limitation of Perforce is that multiple repositories are not really
supported and I think the way svn intend to deal with that is nice. Will it
be possible to merge revisions across repositories ? (would help using
private trees for some work then merge in main one).

Is there any updating on having some kind of � vendor branch � � la CVS ?
If one has general branches, we don't need a special one I guess.

One nice way to � emulate � vendor branch on Perforce is to use "p4 diff -se"
which will give you a list of � changed � files that you feed to "p4 edit"
meaning that it is very easy to have say a tree managed by anoncvs and each
time you update it that way, it is very easy to fold all modifications into
a p4 repo (I even used to do this when the subversion anoncvs was available

Thanks for your work !

PS : stack trace w/o debugging but can do with it if neeed

(gdb) where
#0 0x283457f7 in kill () from /usr/lib/libc.so.5
#1 0x2839770a in abort () from /usr/lib/libc.so.5
#2 0x807f8df in abort_on_pool_failure ()
#3 0x8099b74 in apr_palloc ()
#4 0x8078702 in svn_txdelta ()
#5 0x8078e84 in svn_txdelta_send_stream ()
#6 0x804f394 in send_file_contents ()
#7 0x804f416 in import_file ()
#8 0x804f5d7 in import_dir ()
#9 0x804f587 in import_dir ()
#10 0x804f587 in import_dir ()
#11 0x804f587 in import_dir ()
#12 0x804f7de in import ()
#13 0x804fb57 in send_to_repos ()
#14 0x804fc83 in svn_client_import ()
#15 0x804bc4a in svn_cl__import ()
#16 0x804cb0d in main ()
#17 0x804ab25 in _start ()

Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- roberto@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:37:10 2006

This is an archived mail posted to the Subversion Dev mailing list.

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