Hi Nathan; We did not go down that route -- we simply moved our repositories to a newer-edition Windows file server, and used a DNS alias so that the end-users weren't affected for too long. It is part of our ongoing server refresh plan to move to a svn://- or https://-based solution in the near future, but we needed a short-term fix
The email to users@ was more a PSA than request for help, and also to see if my findings wre matched by anyone else. Thanks, though. J. ----- Original message ----- From: Nathan Hartman <hartman.nat...@gmail.com> To: jimbobmcgee <users~subversion.apache....@jimbobmcgee.com> Cc: users@subversion.apache.org Subject: Re: Windows 10 November 2019 security updates affecting file:// to Win2003 shares? Date: Wednesday, 20 November 2019 17:57 On Wed, Nov 20, 2019 at 10:59 AM jimbobmcgee <users~subversion.apache....@jimbobmcgee.com> wrote: > HI all; > > Appreciating the woefully out-of-date/unsupported nature of my setup, I > thought it might be worth dropping a line to see if anyone else out there > might be experiencing issues since this month's Patch Tuesday release. > > Prior to the November 2019 updates, our Windows 10 users were successfully > using Subversion and/or TortoiseSVN to commit to some old v1.6 repositories > stored on a Windows Server 2003 R2 file share, using the file:// protocol. Have you considered running svnserve on that Windows Server 2003 box and then accessing the repository from your client machines via the svn:// protocol? This will require either re-checking-out working copies on the client machines or updating their URLs with svn switch --relocate (or through TortoiseSVN). Nathan
