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

Re: A failed attempt to introduce Subversion

From: Folker Schamel <schamel23_at_spinor.com>
Date: 2004-03-21 21:05:44 CET

Max Bowsher wrote:

> Folker Schamel wrote:
>
>>
>>Maybe it helps to write your own conversion script.
>
>
> It doesn't work, so start from scratch?
> Totally ignoring the existing code, which represents significant development
> and testing effort?

No, definitely not. Our script called the svn import scriot.
Our script itself was trivially simple, only some few trivial
script lines.

>>We had an 200 MB CVS repository; since we were not interested
>>into keeping the exact history,
>
>
> Most people will want history, though.

my proposal was definitely not ment as universal technique
being the right for everyone.
Since it worked fine for our 200 MB CVS repositry,
my thought simple was it may be an interesting option
for you, too.

BTW, in our case, we explicitely didn't want to retain
CVS history and explicitely only imported CVS tags:
somehow there is no "real" CVS history because
of lack of atomic commits in CVS.
And in our case, the tags contained a senseful history
of snapshots spanning the complete timeline.
But also here, this is only to share some experience
with you, of course it may be not the right approach for you.

>>There are also other indications that the subversion
>>repository storage is very efficient and compact:
>>Our daily backup (uncompressed) svn dump file is much larger
>>than the berkeley database itself (after removing unused logs).
>>Note that dump uses file diff's and therefore does only
>>contain changes (at least for text files).
>
>
> INCORRECT. The dump file does NOT use file diffs, and contains the full text
> of each version of the file. Therefore, the following logic is flawed.

Yes, you are right.

> It *might* be a cvs2svn problem. Or, it might be a repos loader problem. Or,
> it might be some unique environmental oddity. But since we have no evidence
> which it is, don't blame any specific component.

Right, my conclusion was wrong.

Neverthanless, my feeling regarding repository size of
subversion is quite well:
Our old CVS repository which was grown during about 10.5 month
had about 200 MB (we use CVS for much longer, but we had to
reset our repository from time to time, because of the
major slowdown of CVS after many commits).
Then we imported all tags from this CVS repository into Subversion,
then we worked about 4.5 month with Subversion until today.
The subversion repository size now is 224 MB.
You can't draw hard conclusion from it,
but assuming that we didn't do something completely
different, these numbers look good to me:
Importing only tags instead of every commit of course
needs less space, but also contains snapshots of the while
history. You only save memory for multiple changes
on the same file parts, but need the same memory
for independent changes, which are more typical I think.
Again, you cannot draw hard conclusions from this,
but the repository size seems fine to me.

Cheers,
Folker

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 21 21:05:58 2004

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.