On Wed, Sep 16, 2015 at 3:55 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Sep 16, 2015 at 3:47 PM, Eric Johnson <eric_at_tibco.com> wrote:
> Yes, I can do that. Probably going to do that in chunks, otherwise it
>> has the same awful performance profile as svnsync over a low latency
> FWIW, svnsync and svnrdump make identical calls over the network so their
> performance on the network is identical. Of course svnsync can be resumed
> though, so I would use that.
> Your problems make me wonder how svnsync would handle this same problem
> though. I suppose if svnrdump ends with an error, then we can assume
> svnsync does as well and does not sync the transaction that fails. So it
> probably handles it better.
> Unless you have a specific reason to use a dump file, I would use svnsync
> to a local file:// URL.
Old thread on this topic:
I recall doing testing in a pristine environment and the Apache server logs
of the server with the repository being "synched" were identical when using
svnrdump or svnsync to transfer entire repository. At the time I was
surprised by this and was hoping I could build something with svnrdump to
do a faster initial sync of a repository.
Anyway, for your use case it sounds like svnsync would be the right
option. In fact, I think it pretty much is always the right option unless
you really need a dump stream -- such as for Git import.
Received on 2015-09-16 22:02:13 CEST