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

Re: various questions related to repo size

From: <sussman_at_collab.net>
Date: 2003-01-30 14:49:46 CET

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

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.