On Sun, May 22, 2022 at 12:02 PM Andreas Stieger <andreas.stie...@gmx.de> wrote: > > > On 5/22/22 14:40, Nico Kadel-Garcia wrote: > > Why would you want to move a Subversion server to a Windows system? > > > Because that is what poster said they were migrating from. In existing > deployments keeping the current authentication, logging and > administration experience is probably more important than tweaks. So > let's assume that this is on purpose.
>From a considerable amount of painful experience with multiple platforms, I suggest that the Windows backups and scripting would be better discarded and re-implemented for the Linux based environment. Many of them may require no tweaking, depending on the Windows server environment. System stability and security are likelier to be much better, as is system performance. Been there, done that, have the scar tissue. > > Definitely activate an svnsync to allow the new service to run in > > parallel for a while, and to avoid any split-brain issues. > > Only if they cannot deal with a short migration read-only or down time. I've made that "this will be only for a moment" prediction before. I'll leave out the rude metaphors, but the claim is usually about as reliable as a debtor saying "the check is in the mail". Especially for a bulky server, with bulky commits the "out of service" time can tke hours. Never schedule a system upgrade to occur with backup and transfer in a tight time window if you can avoid it gracefully, and "svnsync" allows pre-synchronization with a top-up of the last few commots at switchover time. It's normally much, much cleaner, especially with repos that have bulky binaries among old commits. > > Andreas >
