how to setup azure storage blob container as SVN repository accessible by TortoiseSVN

Question

I have an azure storage account and blob containers inside an StorageV2 and installed TortoiseSVN on my local windows machine. What do I have to configure / setup to use the blob-container as a file-repository with TortoiseSVN?

Answer 1

If you want to host your Subversion repository on Azure, you need to deploy a Subversion server on Azure VM and access your repositories using HTTP(S) or the svnserve protocol. There is no need to use file shares for blob storage.

1. Create a Windows VM in Azure.
2. Add a managed data disk (which is essentially a page blob, BTW). SSD is recommended for better performance.
3. Install VisualSVN Server on the VM and configure it to store the repositories on the managed disk.

You'll also need to open HTTPS port 443 so that end users may access your repositories. And that's all.

Regarding using blob storage:

You cannot store the Subversion repository or a working copy in Azure Blob Storage. AFAIK, neither Subversion nor Azure Blob Storage was designed for this. And I don't understand how this idea came up in the first place. How do you plan on using big data analytics from Azure Data Lake with a set of binary revision files (files that are stored in the repository's /db/revs/ directory)?

Subversion needs an actual filesystem to work. The current format of the Subversion repository backend is FSFS (filesystem-based file system if I remember it correctly), which needs to be stored on a real file system and Azure Blob Storage does not provide it. You can't treat Blob storage as a disk and mount it. Blob storage as a cloud-native object storage by default has a flat namespace without even supporting directories as true file systems do. And I'm pretty sure that it does not meet other requirements to storage Subversion has.

Perhaps it's technically possible to use Azure Files storage with SMB2.1+ protocol to host Subversion repositories, but it's absolutely not recommended because you'll get the worst possible performance when working with such a remote repository.

Note that accessing a Subversion repository in serverless mode using the file:// protocol is by itself OK when you are the only user of the repository and don't need any advanced features, but the repository should be hosted locally on your computer. If you need remote access or the repository has several users, then you need to deploy a Subversion server.