[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-21 07:09:55 CEST

cmpilato@collab.net wrote:
>
> Blair Zajac <blair@orcaware.com> writes:
>
> > 1) Rename hot-backup.py to hot-backup-db.py. No other changes.
>
> Fine by me.
>
> > 2) Create a new hot-backup-repos.py script that creates a single
> > file using svnadmin dump --incremental for each revision in the
> > repository. The filename will have a format
> > svn-dump-v%d-rev%d
> > Here the first %d is the SVN-fs-dump-format-version format
> > number and the second %d is the revision number.
> >
> > The backup program will go through each revision in the
> > repository and dump that revision if the file does not
> > exist. When there's an upgrade to the dump file format,
> > the program will automatically create all the revision
> > dumps automatically because the files will not exist.
>
> So, the rule is:
>
> if (backup file exists)
> svnadmin dump --incremental last-rev > backup_file
> else
> svnadmin dump --incremental 0 last-rev > backup_file

No, I was thinking this

for (rev=0; rev<=youngest; ++rev)
  {
    sprintf(filename, "backup_file_v_%d_rev_%d", dump_format_ver,
            rev);
    if (exists filename)
      continue;
    if (rev)
      svnadmin dump --incremental rev > filename
    else
      svnadmin dump 0 > filename

Each revision gets its own backup file. I don't mind keeping a
separate file for each revision and it's easy to keep track of
which revisions have been dumped.

>
> ?
>
> Because, once we hit 1.0, we will most likely have to support old
> versions of the dumpfile format forever.

I'd rather not support old dump format versions if we don't need
to. If we use the dump version number in the dump filename, then
a new dump format would cause the backup script write new backup
files for each revision.

> If that is what we decide to
> do, you don't need multiple dump files, because each time you run
> svnadmin dump (even with --incremental) the first line of output is
> the format header. svnadmin load would then need only to maintain a
> version "state" of sorts:
>
> SVN-fs-dump-format-version: 1
> Revision-number: 0
> blah blah blah blah
>
> Revision-number: 1
> blah blah blah blah
>
> SVN-fs-dump-format-version: 1
> Revision-number: 2
> blah blah blah blah
>
> SVN-fs-dump-format-version: 1
> Revision-number: 3
> blah blah blah blah
>
> SVN-fs-dump-format-version: 2 <--- BOOM, right here, starting loading
> Revision-number: 4 from the new format
> blah blah blah blah
>
> SVN-fs-dump-format-version: 2
> Revision-number: 5
> blah blah blah blah
>
> > Obviously, revision 0 will not use the --incremental option.
>
> Actually, I *think* I coded it so that --incremental doesn't affect
> revision 0. Aren't I thoughtful? :-)

Yessireee :)

Best,
Blair

-- 
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 Wed Aug 21 07:10:32 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.