subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Victor Sudakov <>
Subject Re: "svnadmin load" a huge file
Date Fri, 07 Jan 2011 19:31:03 GMT
Les Mikesell wrote:
> >
> >>>>I migrated a large CVS repository (25-50 GB) to SVN years ago on SVN
> >>>>1.3.  Our repo had many sections (projects) within it.  We had to
> >>>>migrate each project independently so that it's team could coordinate
> >>>>when they migrated to SVN.  As such, I dumped each project when ready
> >>>>and then svnadmin loaded each dump into it's own path/root (so as not
> >>>>overwrite anything previously loaded and unrelated to this project's
> >>>>import).
> >>>>
> >
> >It would be fine if the project in question did not contain almost all
> >the files in one directory. You may call the layout silly, but CVS does
> >not seem to mind. OTOH, I would have distributed the files over
> >several subdirectories, but CVS does not handle moving files well.
> >
> >I wonder if cvs2svn is to blame that it produces a dump svnadmin
> >cannot load. Or I am always risking that "svnadmin dump" may one day
> >produce a dump a subsequent "svnadmin load" will be unable to swallow?
> >
> >I mean, if by hook or by crook, by using third party utilities like
> >svndumptool, I will eventually be able to convert this project from
> >CVS to SVN. Is there a chance that a subsequent dump will be again
> >unloadable?
> I don't think you are hitting some absolute limit in the software here, 
> just running out of RAM on your particular machine.  Can you do the 
> conversion on a machine with more RAM?

I ran "svnadmin load" on a machine with 1 GB RAM and 25 GB swap (added
so much swap specially for the occasion). svnadmin crashed after
reaching the SIZE about 2.5 GB.

Is 1 GB RAM and 25 GB swap not enough?

I don't know if this gdb output will be useful:

(gdb) where
#0  0x2841e117 in kill () from /lib/
#1  0x2841e076 in raise () from /lib/
#2  0x2841cc4a in abort () from /lib/
#3  0x28116ec5 in abort_on_pool_failure (retcode=Could not find the frame base f
or "abort_on_pool_failure".
    at subversion/libsvn_subr/pool.c:49
#4  0x283095fb in apr_palloc (pool=0xba46d018, in_size=204800)
    at memory/unix/apr_pools.c:663
#5  0x280ebad3 in svn_txdelta_target_push (
    handler=0x280eb140 <window_handler>, handler_baton=0x5b26c058,
    source=0xba470738, pool=0xba46d018)
    at subversion/libsvn_delta/text_delta.c:528
#6  0x280d4d62 in svn_fs_fs__set_contents (stream=0xbfbfe7e4, fs=0x28512020,
    noderev=0x27dea528, pool=0x2852a018)
    at subversion/libsvn_fs_fs/fs_fs.c:5066
#7  0x280c9d52 in svn_fs_fs__dag_get_edit_stream (contents=0x2852a138,
    file=0x5b2e61a0, pool=0x2852a018) at subversion/libsvn_fs_fs/dag.c:997
#8  0x280de42e in fs_apply_text (contents_p=0xbfbfe904, root=0x5aef8058,
    path=0x2852a080 "ns2/trunk/", result_checksum=0x2852a110,
    pool=0x2852a018) at subversion/libsvn_fs_fs/tree.c:2615
#9  0x280bf44e in svn_fs_apply_text (contents_p=0xbfbfe904, root=0x5aef8058,
    path=0x2852a080 "ns2/trunk/",
    result_checksum=0x2852a0e8 "b03cbddfbc11be113cbf675862eb971e",
    pool=0x2852a018) at subversion/libsvn_fs/fs-loader.c:1096
---Type <return> to continue, or q <return> to quit---

Victor Sudakov,  VAS4-RIPE, VAS47-RIPN

View raw message