What does the migration look like? Will users just have to re-accept the cert?
Use the database as the location for SVN certificate acceptance storage.
Review Request #3420 — Created Oct. 15, 2012 and submitted
Use the database as the location for SVN certificate acceptance storage. Our cert model for Subversion worked such that when the user confirmed a cert before adding a repository, we would tell Subversion to go ahead and save that cert to the local ~/.subversion/auth. If the cert file wasn't there, file fetches would fail. This made it quite annoying to have a multi-server deployment, as that directory would have to be shared. Now, upon acceptance of the cert, we store the cert information in the repository's extra_data field. We then look it up from there if pysvn tells us it needs verification again on a cert. We still save on the filesystem as well, which is more convenient, but we're far more resilient now. We can work multi-server, and we can easily nuke the auth directory, without affecting file fetches. We also still generate the Subversion config files to configure rbssh usage for Local Sites, but these are already resilient enough by themselves, as they're just recreated as needed. So now, Subversion should work perfectly fine without having to have a permanent .subversion directory.
Started by turning off automatic trusting of default CAs, requiring every single cert to be manually verified. Configured an HTTPS repository without this patch. Verified the cert file in the .subversion directory. Nuked that cert, and then tried accessing a diff. Saw the cert verification failure errors. Then applied this patch and re-saved the repository. Saw the cert file and the cert info in the database. Accessed the files without problems. Deleted the cert file, but kept the info in the database. Cleared the cache. Re-accessed the file. It worked fine. Saw that SVN took the in-database cert and re-saved it in the .subversion/auth directory. Repeated another time just to be sure.