| 1 |
Paul de Vrieze wrote: |
| 2 |
> On Monday 19 January 2004 16:26, Mike Williams wrote: |
| 3 |
> |
| 4 |
>>On Monday 19 January 2004 15:18, John Nilsson wrote: |
| 5 |
>> |
| 6 |
>>>Is there any particular feature in cvs that subversion could not provide? |
| 7 |
>> |
| 8 |
>>A stable DB format? :) |
| 9 |
> |
| 10 |
> |
| 11 |
> That and the fact that the database is very very big. |
| 12 |
|
| 13 |
Attached is a recent test i did on subversion regarding exactly this, the the |
| 14 |
size of the repository I came to the same conclusion as you (the db is big) in |
| 15 |
this case 161MB for a raw import of portage versus CVS's 70MB. |
| 16 |
|
| 17 |
However this is due to the Berkley DB leaving behind a lot of log files which |
| 18 |
in all normal use are usless and can be safely deleted. (these are not the |
| 19 |
commit-diffs) |
| 20 |
|
| 21 |
After i deleted these unused log-files the previously 161MB subversion |
| 22 |
repository of portage took 49MB or more then threefold reduction in size |
| 23 |
without any loss of version info or files. |
| 24 |
More info can be found in the subversion manual at -> project_faq.html#bdblogs |
| 25 |
which deals specifically with why the repository gets so big. |
| 26 |
|
| 27 |
The subversion admin can regularly remove these logfiles from the repository |
| 28 |
through the use of a cron job in older versions or just leave the default |
| 29 |
log-pruning on in versions >=0.35. |
| 30 |
|
| 31 |
So not only was the statement about subversions database being bigger wrong, |
| 32 |
its quite the opposite; its smaller. |
| 33 |
|
| 34 |
> That would make |
| 35 |
> subversion dumps quite painfull. Further subversion is not really good in |
| 36 |
> such big repositories |
| 37 |
|
| 38 |
Elaborate, why does it not handle the big ones well? |
| 39 |
|
| 40 |
> in any case, although that might have improved since I last tested |
| 41 |
> importing a portage tree. |
| 42 |
> |
| 43 |
> Paul |
| 44 |
> |
| 45 |
|
| 46 |
Ævar Arnfjörð Bjarmason |
Archives