Jani Monoses jani@iv.ro writes:
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
Ah, ok.
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.
Yes, the working copies are roughly twice as big as the original tree
you imported into the repository. That's normal. Every file has a
second cached pristine copy within .svn/text-base/, so that svn can
perform many disconnected operations.
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.
We plan to automate it. IIRC, the next version of Berkeley DB will
automate it for us.
---------------------------------------------------------------------
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:20 2006