On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann <ehuels_at_gmail.com> wrote:
>
> On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>
>> On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <Bob.Archer_at_amsi.com> wrote:
>>
>>
>>> > Until you manually copy over the $repodir/db/uuid file, this is true.
>>> > That's one of the "relevant configuraton files" I referred to.
>>>
>>> So, are you saying svnsync will be faster than a dump/load?
>>>
>>> I didn't know the guid was stored in a file.
>>>
>>
>> svnsync is slower than dump/load. I think the issue is that you can keep
>> the old repository online during the process and switch when you are ready.
>>
>
> But there's no difference in running 'checkout' repeatedly, svnsync or
> svnadmin dump; all methods can be used concurrently and don't require taking
> down the repository. Of course, running during the weekend may help mitigate
> the performance effect it may have on users if you start claiming large
> amounts of CPU from your server.
>
Anytime the entire time it takes to dump/load a repository exceeds the
amount of time you can reasonably block writes to the old repository, it is
beneficial to be able to use svnsync. When using svnsync, it can take as
long as it needs to because you have total control over the switchover and
can do it with minimal downtime. But the actual time to do svnsync is
generally longer than dump/load. My point was only that you do not use
svnsync because it is faster, you do it because you can better control and
minimize the downtime.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-08-05 20:03:13 CEST