On Monday 19 January 2004 16:26, Mike Williams wrote:
On Monday 19 January 2004 15:18, John Nilsson wrote:
Is there any particular feature in cvs that subversion could not provide?
A stable DB format? :)
That and the fact that the database is very very big.
Attached is a recent test i did on subversion regarding exactly this, the the size of the repository I came to the same conclusion as you (the db is big) in this case 161MB for a raw import of portage versus CVS's 70MB.
However this is due to the Berkley DB leaving behind a lot of log files which in all normal use are usless and can be safely deleted. (these are not the commit-diffs)
After i deleted these unused log-files the previously 161MB subversion repository of portage took 49MB or more then threefold reduction in size without any loss of version info or files. More info can be found in the subversion manual at -> project_faq.html#bdblogs which deals specifically with why the repository gets so big.
The subversion admin can regularly remove these logfiles from the repository through the use of a cron job in older versions or just leave the default log-pruning on in versions >=0.35.
So not only was the statement about subversions database being bigger wrong, its quite the opposite; its smaller.
> That would make > subversion dumps quite painfull. Further subversion is not really good in > such big repositories
Elaborate, why does it not handle the big ones well?
> in any case, although that might have improved since I last tested > importing a portage tree. > > Paul >
�var Arnfj�r� Bjarmason
# Making dirs for vcs $ mkdir -p /home/vcs/portage_cvs $ mkdir -p /home/vcs/portage_svn
# Making dirs for portage
$ mkdir /home/jeedo/portage
$ cd /home/jeedo/portage
# Cleaning portage
$ cp -R /usr/portage/*-* .
$ find -type d -iname 'files' -exec rm -rf {} \;
$ find -type f -iname 'Changelog' -exec rm -rf {} \;
$ find -type f -iname 'Manifest' -exec rm -rf {} \;
# Checking size
$ cd /home/jeedo/portage
$ du -sh && du -s
70M .
70867 .
# Importing to CVS
$ export CVSROOT="/home/vcs/portage_cvs"
$ cvs init
$ time cvs import -m "Initial Import" portage vendor start
[...]
real 1m11.072s
user 0m4.380s
sys 0m11.210s
# Importing to SVN
$ svnadmin create /home/vcs/portage_svn/
$ time svn import -m "First import" ./ file:///home/vcs/portage_svn/
[...]
real 12m58.771s
user 2m10.090s
sys 1m3.130s
# Checking the size of newly-imported stuff
$ cd /home/vcs/
$ du -sh * && du -s *
70M portage_cvs
161M portage_svn
71456 portage_cvs
164575 portage_svn
# Making working directories
$ mkdir /home/jeedo/portage_work_cvs
$ mkdir /home/jeedo/portage_work_svn
# Checking out the CVS tree
$ export CVSROOT="/home/vcs/portage_cvs"
$ cd /home/jeedo/portage_work_cvs
$ time cvs co portage
[...]
real 1m40.417s
user 0m12.780s
sys 0m36.700s
# Checking out the SVN tree
$ cd /home/jeedo/portage_work_svn
$ time svn co file:///home/vcs/portage_svn/
[...]
real 6m20.541s
user 1m57.390s
sys 1m41.810s
# Conclusion
Importing to SVN takes almost 11 times as much time as importing to CVS (
778.771/71.072
10.95749380909500225123
)
And takes more than 2 times as much space (
164575/71456
2.3031655844155844155
)
-- [EMAIL PROTECTED] mailing list
