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

Re: Hot backup changes

From: Blair Zajac <blair_at_orcaware.com>
Date: 2002-08-22 18:00:22 CEST

cmpilato@collab.net wrote:
>
> Blair Zajac <blair@orcaware.com> writes:
>
> > > Actually, a really simple script that wrapped `svnlook log old-repos' and
> > > `svnadmin setlog new-repos' could do the trick, I imagine. Both
> > > operations are pretty darn fast.
> >
> > True, but on the current svn repository, that would mean forking at
> > least 3000 processes, which is too many.
>
> Nonono. I mean, don't sweat the log stuff during your incremental
> dumps. Just, at the time you go to *load* your dumps, keep your old
> repos around so you can fly over it, reading the logs, and updating
> them on the newly-loaded repos. Obviously, this is no good if your
> reason for re-loading your repos is because your old one got blown to
> a cloud of pink mist by a photon torpedo.

I do need to sweat the log stuff doing the incremental backups.

I plan on replacing the db backup solution with the svnadmin dump based
backup solution due to the large disk space that the db based backups
are using, I indicated my the first message in this thread.

So this needs to be a real backup solution. Having a dump solution that
has old log messages in it is not an acceptable solution.

Instead of adding a new table to the repos, the backup script can run
`svn log' on the whole repository to get all the log messages, parse
them into individual revision messages and compare each revision message
with a copy of the previous log message. If they differ, then dump that
one revision again.

If anybody needs to restore from this backup, then they don't need to
worry about the log messages being up to date.

>
> > How about adding a new table to the repository that just stores a
> > binary flag indicating for a particular revision if the log message
> > has been modified. Then we can have several new svnadmin commands
> > (these aren't the best names)
> >
> > svnadmin logs_get_set just prints those revision numbers
> > with set bits
> > svnadmin logs_clear_change takes a list of revisions to clear
> > the bit
> >
> > This bit gets set whenever `svnadmin setlog' or a `svn commit' runs
> > on the repos. Then the hot backup script runs `svnadmin logs_get_set'
> > and only runs `svnlook log' on the indicated revisions.
>
> /me revokes Blair's Developer role on tigris.org...

-- 
Blair Zajac <blair@orcaware.com>
Web and OS performance plots - http://www.orcaware.com/orca/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 22 18:01:08 2002

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.