Jani Monoses jani@iv.ro writes:
I had a repo and 3 workspaces.Moved the kernel tree into one and
checked it in. It lasted over half an hour and after two screenfuls
of dots it said Killed.
I think this is a known scalability bug that we'll tackle soon.
Now I updated the 2 other workspaces (one ra_local other ra_svn from
localhost) After a while they had the kernel tree but those
workspaces are 534Megs each.
Do you mean, you checked out two independent working copies?
1) Aren't 2 workspaces supposed to be equal if everything is
commited from one and updated form the other?The difference is
.svn/prop and ./svn/prop-base files which appear only in the updated
WS not the original.
I don't understand. In the previous paragraph, it sounds like you
checked out two working copies using two different RA methods. In
this paragraph, you say you committed from one and updated from the
other. Can you clarify?
2) The repository seemed to grow while the WS was updating.About
300M for each WS.Why should the repo care about an update and use up
so much space?It is in log.XXXXXXXX files which according to a mail
from Brane dated Jan 13th are required.The more clients the more the
repo grows? Does it keep some sort of repository for each client
separately?I don't think so because if one deletes a WS the repo
shouldn't care but the extra hundreds on megs would stay there.
'svn up' creates a temporary mirror of the working copy in the
repository, compares it to the HEAD tree to perform a tree delta, then
removes the temporary mirror.
Thus even 'svn up' requires Berkeley DB to temporarily write new
data. What you're witnessing is BDB logging all of these writes.
Luckily, you can use 'db_archive' to throw away old logfiles. It's
all documented in the subversion book.
Just run 'db_archive -a -h repos/db/', and it will tell you which log
files can be deleted. Make sure you use the CORRECT version of
db_archive, or you'll get a big error that forces you to repair the
repository. (Actually, CMike -- you never say 'db_archive -a' in
Chapter 5... it might be more useful to be explicit there.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:25:15 2006