kfogel@collab.net wrote:
> Mikhail Terekhov <termim@charter.net> writes:
>
>>That would be very surprising! The closer dump format reflects
>>internal DB structure
>>the faster should be dump/load operations IMHO. Storing file deltas
>>instead of full file
>>content should eliminate applying deltas on dump and calculating them
>>on load.
>
>
> I don't believe it works that way, unfortunately.
It solves another problem then, unfortunately.
>
>
>>>Is it 10 days or the 43GB which makes it impossible to convert your
>>>project (with cvs2svn, I presume, though you didn't say)? The 43GB
>>>shouldn't matter, as you can convert without having a full
>>>intermediate dumpfile at any point.
>>>
>>
>>10 days of course! Profiling with oprofile shows that more than 33% of
>>this time is spent
>>in libsvn_delta (vdelta), around 9% in reiserfs, about 8.5% in
>>libaprutil-0(MD5Transform)
>>etc. From this I suppose that most of the time in cvs2svn conversion
>>is spent on calculating
>>deltas which we already have from cvs.
>
>
> We don't really have them from CVS. CVS has one kind of delta, we
> have another.
I thought that convert one kind of delta to another is much less
expensive than calculate it anew, plus huge savings in space.
>
> But is that 10 days to load the dumpfile, or 10 days to convert the
> project? If the latter, I highly doubt 33% of total conversion time
> is spent in Subversion's vdelta code -- much more likely it is spent
> in cvs2svn.py.
It takes 3+ days to create the dumpfile and 10+ days to load it.
CVS repository ~ 770M, 8+K files.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jun 19 08:24:32 2004