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?
Kind of.Because those were already checked out but contained a few small test files.
I tested those and were fine so I said lets see something big.
So updated two independent working copies after commiting a kernel tree from the third WC
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?
So the original WS is 290Megs the one from which I commited the kernel.
The two other WCs (local and ra_svn) after update are both 534M.
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
So this means someone has to constantly keep an eye on the repo and delete
log files.Is this not automated because right now it can be used for debugging or what?
IMHO the server should figure out what's unnecessary and clean up itself.
Thanks
---------------------------------------------------------------------
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:17 2006