1 |
On Saturday 24 January 2004 17:37, Ævar Arnfjörð Bjarmason wrote: |
2 |
> Attached is a recent test i did on subversion regarding exactly this, the |
3 |
> the size of the repository I came to the same conclusion as you (the db is |
4 |
> big) in this case 161MB for a raw import of portage versus CVS's 70MB. |
5 |
> |
6 |
> However this is due to the Berkley DB leaving behind a lot of log files |
7 |
> which in all normal use are usless and can be safely deleted. (these are |
8 |
> not the commit-diffs) |
9 |
> |
10 |
> After i deleted these unused log-files the previously 161MB subversion |
11 |
> repository of portage took 49MB or more then threefold reduction in size |
12 |
> without any loss of version info or files. |
13 |
> More info can be found in the subversion manual at -> |
14 |
> project_faq.html#bdblogs which deals specifically with why the repository |
15 |
> gets so big. |
16 |
> |
17 |
> The subversion admin can regularly remove these logfiles from the |
18 |
> repository through the use of a cron job in older versions or just leave |
19 |
> the default log-pruning on in versions >=0.35. |
20 |
> |
21 |
> So not only was the statement about subversions database being bigger |
22 |
> wrong, its quite the opposite; its smaller. |
23 |
> |
24 |
> > That would make |
25 |
> > subversion dumps quite painfull. Further subversion is not really good |
26 |
> > in such big repositories |
27 |
> |
28 |
> Elaborate, why does it not handle the big ones well? |
29 |
> |
30 |
|
31 |
I have not tested it in a long while. What happened was that IF I was able to |
32 |
actually check in the whole tree into the repository checking out would both |
33 |
take too much time and fail somewhere in the meantime on some lock or |
34 |
out-of-memory error. |
35 |
|
36 |
It can very well be that this has been fixed by now, but I didn't check. |
37 |
|
38 |
Paul |
39 |
|
40 |
-- |
41 |
Paul de Vrieze |
42 |
Gentoo Developer |
43 |
Mail: pauldv@g.o |
44 |
Homepage: http://www.devrieze.net |