subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Barry Gershenfeld <gbarr...@gmail.com>
Subject Re: SVN 1.6.17 dump is growing larger than repository size (approx. more than 10 times)
Date Wed, 25 Nov 2015 20:57:19 GMT
Unless svn's changed, you can look in your repositories directory on the
server, e.g., repos/myproj/db/revs/0/ and you can see each revision stored
there.  Under the db directory is revs and also revprops, and under each of
those is one or more subdirectory (mine just had one called "0").   If you
see one that is outrageously large, then dump is just trying to do its
job.  If they are all reasonable size, then maybe there's a circular
reference or some other bug.

Also, svnadmin dump just goes to standard-out, so you can send it to the
screen, or through a grep filter or some other ingenious scheme to try to
get a handle on what's happening.

Barry



On Wed, Nov 25, 2015 at 4:41 AM, Nico Kadel-Garcia <nkadel@gmail.com> wrote:

> On Wed, Nov 25, 2015 at 4:25 AM, arun prasath <get2arun@gmail.com> wrote:
> > Hello Team,
> >
> > I am creating Subversion 1.6.17 dump for a repository hosted in Linux
> > server. SVNSERVE is serving the repository. We are migrating to SVN
> 1.9.2.
> >
> > While creating the dump for repository of size 1.8 GB (revisions 3000+),
> the
> > dump command completes revision 119 and hangs and keep updating the
> dumpfile
> > which grows to 7-8 GBs. dump command is not moving to next revision but
> kept
> > updating the dump file. So, i just closed the putty to stop creating the
> > dump.
>
> Which Linux? And are you using the verndor provided version, or a
> locally compiled one? Subversion 1.6 was last up to 1.6.23: is there
> any reason you can't upgrade that? Ideally with a hotcopy or "rsync"
> based copy of the repository to somehwere else, for testing the copy?
>
> > However, I ran the svnadmin verify which completes revision 119 and take
> > some time to verify revision 120 and complete the verification
> successfully
> > for all the repository revisions.
>
> Hmm. You might consider skipping the svnadmin dump command, and simply
> setting up an svnsync mirror on the Subversion 1.9 server. Even using
> "rsync" to bring the old repository over should let you run a dump and
> reload on the server with Subversion 1.9, as long as there's not some
> other weird corruption with revision 119 or 120.
>
> > Since, there is no error output I have no logs to attach. Please suggest
> the
> > work around for this situation. How can create the dump and migrate to
> > target server. I am planning to use rsync from the server. I will post
> how
> > it goes.
> >
> > I am expecting the workaround to this situation and let me know if this
> is a
> > known issue in SVN 1.6.17. This is my active repository and created the
> dump
> > without stopping the svnserve program in the production server.
>
> It's not one I've seen, but I don't let my repositories get that big.
> And I'd look at revisions 119 and 120 to see if there were erroneous
> commits of huge binary files, in which case I'd want to exclude them
> from the backup.
>

Mime
View raw message