Philip Martin wrote on Sat, Feb 19, 2011 at 10:30:17 +:
> Philip Martin writes:
>
> > Daniel Shahaf writes:
> >>
> >> Either method would need to account for old-revprop changes and for 'svn
> >> lock' locks.
> >
> > Unless we start recording some sort of history for revprops the only
> > op
Philip Martin writes:
> Daniel Shahaf writes:
>>
>> Either method would need to account for old-revprop changes and for 'svn
>> lock' locks.
>
> Unless we start recording some sort of history for revprops the only
> option for svnsync is to resend all revprops, hotcopy has more options.
As you
Daniel Shahaf writes:
> Philip Martin wrote on Sat, Feb 19, 2011 at 09:43:49 +:
>> At the moment svnsync doesn't do exclusive file locks or old
>> revprops that have changed. svnsync is unlikely to ever update old
>> revprops automatically, it is likely that it will always need some
>> exter
Daniel Shahaf wrote on Sat, Feb 19, 2011 at 11:45:54 +0200:
> (For example, WebDAV mirrors also suffer from both of these problems)
Oops; I already said that in another mail. Sorry for the duplication.
Philip Martin wrote on Sat, Feb 19, 2011 at 09:43:49 +:
> Daniel Shahaf writes:
>
> > Why can't you svnsync the master to the hotcopy using file:// URLs?
> > (and create the svn:sync-* props before / remove them after, if that's
> > a problem)
>
> That's one option. svnsync is probably less
Daniel Shahaf writes:
> Why can't you svnsync the master to the hotcopy using file:// URLs?
> (and create the svn:sync-* props before / remove them after, if that's
> a problem)
That's one option. svnsync is probably less efficient in terms of disk
IO. At the moment svnsync doesn't do exclusiv
On Thu, Feb 17, 2011 at 01:26:55PM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, Feb 17, 2011 at 12:29:09 +0100:
> > On Thu, Feb 17, 2011 at 01:14:40PM +0200, Daniel Shahaf wrote:
> > > Stefan Sperling wrote on Thu, Feb 17, 2011 at 12:11:06 +0100:
> > > > People are using rsync instea
Stefan Sperling wrote on Thu, Feb 17, 2011 at 12:29:09 +0100:
> On Thu, Feb 17, 2011 at 01:14:40PM +0200, Daniel Shahaf wrote:
> > Stefan Sperling wrote on Thu, Feb 17, 2011 at 12:11:06 +0100:
> > > People are using rsync instead of hotcopy for this reason (and as long
> > > 'current' is copied fir
Philip Martin writes:
> rsync on a live repository is becoming less reliable: it doesn't handle
> exclusive file locks (issue 3750) or 1.7 packed revprops.
The rep-cache is a problem as well.
--
Philip
On Thu, Feb 17, 2011 at 01:14:40PM +0200, Daniel Shahaf wrote:
> Stefan Sperling wrote on Thu, Feb 17, 2011 at 12:11:06 +0100:
> > People are using rsync instead of hotcopy for this reason (and as long
> > 'current' is copied first this is probably the best way of making
> > incremental
> > backup
Stefan Sperling wrote on Thu, Feb 17, 2011 at 12:11:06 +0100:
> People are using rsync instead of hotcopy for this reason (and as long
> 'current' is copied first this is probably the best way of making incremental
> backups).
Nowadays 'svnadmin recover' can recreate 'current', can't it?
Stefan Sperling writes:
> It would be nice to come up with a solution that leaves the repository
> in a well-defined state even if the operation is interrupted. rsync cannot
> do that.
So long as we do things in a reasonable order it will probably be
possible to restart the incremental hotcopy e
On Thu, Feb 17, 2011 at 10:54:38AM +, Philip Martin wrote:
> Somebody responsible for backing up a large FSFS repository asked me if
> it were possible to do an incremental hotcopy. An incremental hotcopy
> would update a previous hotcopy to the current HEAD and would only need
> to copy the r
Why can't you svnsync the master to the hotcopy using file:// URLs?
(and create the svn:sync-* props before / remove them after, if that's
a problem)
Philip Martin wrote on Thu, Feb 17, 2011 at 10:54:38 +:
> Somebody responsible for backing up a large FSFS repository asked me if
> it were poss
Somebody responsible for backing up a large FSFS repository asked me if
it were possible to do an incremental hotcopy. An incremental hotcopy
would update a previous hotcopy to the current HEAD and would only need
to copy the rev files newer than the previous hotcopy. This might
involve deleting
15 matches
Mail list logo
