Conservation is always good so I’m going to recycle some keystrokes. Today I got an email where a company had two symbol servers set up. One was no longer used but held symbols for previously released projects. Since PDB files are as important as source code, they wanted to know if there was a way to merge the symbol servers together.
Since symbol servers are a file system used as a database, with a storage scheme of \ServerShareFile.PDBGUIDFile.PDB, one could drag the files in Explorer from one symbol server to another. That’s not ideal because if you’re actively managing your symbol server to prune dead symbols, those added through drag and drop are stuck there forever. To avoid the dead symbols problem, you just need to run the same command that got the build into the symbol server to begin with: SYMSTORE.EXE, which is part of the Debugging Tools for Windows (AKA WinDBG) you can install as part of the Windows SDK.
This case was simple, but what if you had a more complicated situation where the retiring symbol server was correctly used and had daily builds going back ages, but you only wanted just the externally released product builds? Let’s make it more interesting in that you wanted the ability to prune the individual builds down the road. Say for example, the alpha release or daily builds more than two months old? (I’m assuming you’ve read the documentation on symbol servers and set one up. If you haven’t here’s where to start: http://msdn.microsoft.com/en-us/library/windows/desktop/ms680693(v=vs.85).aspx)
Fortunately, merging symbol servers and keeping all the add data such as version, product, and allowing for individual builds is doable, but would have to be scripted. Looking at the problem a little bit, here’s the basic algorithm you’d have to follow.
While only maybe two people in the world would ever need to merge symbol servers at this level, but since I had gone through the mental steps I thought I’d blog it. For those two people, I hope you find this useful.