> On Fri, Aug 5, 2011 at 1:51 PM, Erik Huelsmann <ehu...@gmail.com> wrote: > > On Fri, Aug 5, 2011 at 7:27 PM, Mark Phippard <markp...@gmail.com> > wrote: > On Fri, Aug 5, 2011 at 1:19 PM, Bob Archer <bob.arc...@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.
I'm never sure... should I dump with 1.6 binaries and then load with 1.7 binaries. Or, upgrade the binaries and then dump and load with the most recent binaries? Or does it not matter since the dump file format is the same for all 1.x versions? BOb
