On 02/15/2012 11:05 AM, Philip Martin wrote:
Stefan Sperlings...@elego.de writes:
But rather than going through that effort, I would recommend using
svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
is released. At which point you can switch over to using
svnadmin hotcopy
On Thu, Feb 16, 2012 at 03:56:29AM +0200, Daniel Shahaf wrote:
Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Nico Kadel-Garcia nka...@gmail.com writes:
Unless you do a sync
command,
On Thu, Feb 16, 2012 at 6:53 AM, Stefan Sperling s...@elego.de wrote:
There is no window of vulnerability.
What if the disk controller lies and sends the acknowledgement before
the actual work has completed (e.g. it cached the write request and is
going to get to it soon)? How can the OS
Stefan Sperling wrote on Thu, Feb 16, 2012 at 13:53:04 +0100:
On Thu, Feb 16, 2012 at 03:56:29AM +0200, Daniel Shahaf wrote:
Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Nico
On Wed, Feb 15, 2012 at 03:02:04AM +0200, Daniel Shahaf wrote:
Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
Until then, svnsync or svnadmin dump/load are the only officially
supported incremental backup solutions. But, as Daniel explained,
'rsync' followed by 'svnadmin
On Wed, Feb 15, 2012 at 6:24 AM, Stefan Sperling s...@elego.de wrote:
On Wed, Feb 15, 2012 at 03:02:04AM +0200, Daniel Shahaf wrote:
Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
Until then, svnsync or svnadmin dump/load are the only officially
supported incremental backup
Harry Bullen wrote on Wed, Feb 15, 2012 at 12:03:15 -0500:
On Wed, Feb 15, 2012 at 6:24 AM, Stefan Sperling s...@elego.de wrote:
On Wed, Feb 15, 2012 at 03:02:04AM +0200, Daniel Shahaf wrote:
Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
Until then, svnsync or svnadmin
On Wed, Feb 15, 2012 at 12:03:15PM -0500, Harry Bullen wrote:
From what I gather rep-cache.db, can be
regenerated by svn. If I used rsync and excluded the rep-cache.db
would I then want to run 'svnadmin recover' on these backup or is
rep-cache.db regenerated automatically when the repository
Stefan Sperling s...@elego.de writes:
But rather than going through that effort, I would recommend using
svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
is released. At which point you can switch over to using
svnadmin hotcopy --incremental, which will copy rep-cache.db
On Wed, Feb 15, 2012 at 07:05:08PM +, Philip Martin wrote:
Stefan Sperling s...@elego.de writes:
But rather than going through that effort, I would recommend using
svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
is released. At which point you can switch over to
On Wed, 15 Feb 2012 20:41:48 +, Stefan Sperling wrote:
I don't know enough about SQlite to judge whether the DB will
keep working at any frozen state a snapshot might create.
If it doesn't then it wouldn't be resilient to system crashes either,
and *that* wouldn't exactly be a
On Wed, Feb 15, 2012 at 2:05 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Stefan Sperling s...@elego.de writes:
But rather than going through that effort, I would recommend using
svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8
is released. At which point you can
On Wed, Feb 15, 2012 at 3:37 PM, Nico Kadel-Garcia nka...@gmail.com wrote:
If the repository is busy in a commit or partial commit at the moment
of the snapshot, you're in potentially very deep trouble. You've
entered not only split-brain territory, where the repositories are
out of sync,
Nico Kadel-Garcia nka...@gmail.com writes:
Unless you do a sync
command, or various low level flush commands, you don't know that you
write to disk has actually made it to the platter.
Subversion does that. It uses fsync (plus fsync on directories on
Linux) before assuming data is on disk.
On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Nico Kadel-Garcia nka...@gmail.com writes:
Unless you do a sync
command, or various low level flush commands, you don't know that you
write to disk has actually made it to the platter.
Subversion does that. It
Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500:
On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Nico Kadel-Garcia nka...@gmail.com writes:
Unless you do a sync
command, or various low level flush commands, you don't know that you
write
I'm looking at using lvm snapshots and rsync to back up a bunch of svn
repositories every night. The repositories total about 200GB (some
people might have committed movies to svn but I may not fix this)
which is why I want to do this instead of svn hotcopy, which will have
to copy all 200GB
On Tue, Feb 14, 2012 at 2:11 PM, Harry Bullen hbul...@gmail.com wrote:
I'm looking at using lvm snapshots and rsync to back up a bunch of svn
repositories every night. The repositories total about 200GB (some
people might have committed movies to svn but I may not fix this)
which is why I
If the snapshots are atomic that's fine, though you'll potentially need
to run 'svnadmin recover' before they're usable.
Running dump / verify or otherwise verifying your snapshots remains
a good idea.
Harry Bullen wrote on Tue, Feb 14, 2012 at 14:11:29 -0500:
I'm looking at using lvm snapshots
On Tue, Feb 14, 2012 at 1:11 PM, Harry Bullen hbul...@gmail.com wrote:
I'm looking at using lvm snapshots and rsync to back up a bunch of svn
repositories every night. The repositories total about 200GB (some
people might have committed movies to svn but I may not fix this)
which is why I
On Tue, Feb 14, 2012 at 02:11:29PM -0500, Harry Bullen wrote:
The repositories total about 200GB (some
people might have committed movies to svn but I may not fix this)
which is why I want to do this instead of svn hotcopy, which will have
to copy all 200GB every day.
Subversion 1.8 will ship
Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
Until then, svnsync or svnadmin dump/load are the only officially
supported incremental backup solutions. But, as Daniel explained,
'rsync' followed by 'svnadmin recover' produces valid copies of
FSFS repositories, too.
I didn't
On Tue, Feb 14, 2012 at 7:02 PM, Daniel Shahaf d...@daniel.shahaf.name wrote:
Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
Until then, svnsync or svnadmin dump/load are the only officially
supported incremental backup solutions. But, as Daniel explained,
'rsync' followed by
Les Mikesell wrote on Tue, Feb 14, 2012 at 19:34:10 -0600:
On Tue, Feb 14, 2012 at 7:02 PM, Daniel Shahaf d...@daniel.shahaf.name
wrote:
Stefan Sperling wrote on Tue, Feb 14, 2012 at 23:19:58 +0100:
Until then, svnsync or svnadmin dump/load are the only officially
supported incremental
24 matches
Mail list logo
