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

RE: Deficiency in Subversion - restore breaks working copies

From: James Goodall <jgoodall_at_dmetrix.com>
Date: 2003-08-15 18:35:17 CEST

Eric,

If you demand restorable backups for every revision committed, you might
find this script useful. My paranoia is pretty high and I run it every
night, but you might want to stick it in your post-commit hook script.
(Actually, this very script has saved you quite a bit of work in the past!)

 - James

#!/usr/bin/perl
#
# dump-repos.pl
# Dump all revisions that haven't been dumped since this script last ran
#

use strict;

my $g_repos = '/raid/Software/subversion/svn_repository';
my $g_backup = "$g_repos/../backups";
my $g_lastrev = "$g_backup/last-dumped-rev";
my $g_svnlook = '/usr/local/bin/svnlook';
my $g_svnadmin = '/usr/local/bin/svnadmin';

umask 0177;

# get the starting revision of the dump (0 if we can't figure it out)
my $start = 0;
if (open LASTDUMPED, $g_lastrev)
{
        $start = <LASTDUMPED>;
        chomp $start;
        ++$start;
        close LASTDUMPED;
}

# get the youngest revision in the repository
my $end = `$g_svnlook youngest $g_repos`;
chomp $end;

# make sure there are actually revisions to dump
exit 0 if $start > $end;

# construct the dump file name using the revisions in the dump
my $dumpfile = "$g_backup/repos-backup_$start-$end.dump";

# do the dump
`$g_svnadmin dump $g_repos -r $start:$end --incremental > $dumpfile`;
die 'subversion error dumping revisions' if $?;

# compress the dumpfile
`gzip --best $dumpfile`;

# tighten up permissions on the data
chmod 0400, "$dumpfile.gz";

# store the last dumped revision for next time
open LASTDUMPED, ">$g_lastrev" or die "Unable to open $g_lastrev for
writing";
print LASTDUMPED "$end\n";
close LASTDUMPED;

-----Original Message-----
From: Wadsworth, Eric (Contractor) [mailto:wadswore@fhu.disa.mil]
Sent: Thursday, August 14, 2003 2:39 PM
To: 'John Locke'
Cc: users@subversion.tigris.org
Subject: RE: Deficiency in Subversion - restore breaks working copies

I don't have time for a longer reply, but the thing I just ran into was that
the restored repository was revision #209, and the working copies were at
#222. Thus, all working copies were broken when I restored the backup,
because they were a later version.

So, yes, everyone can check out a new working copy, but then they have to
manually merge their changed files into it... or the admin has to gather all
the best bits from the working copies, and manually merge them in... you see
the mire here. I'm thinking this could be automated, at least partially. Or
at least anticipated, and a robust process recommended for application in
this situation.

--- Eric

> But if you're restoring from a backup, I don't see how that
> breaks the working copies.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Aug 15 18:36:09 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.