Okay.

As I download VS Express so that I can test it in that environment, I’ve uploaded two patches in the continuing saga that is Source Server.

Here’s what we’ve learned since my last post:

* cvs.exe that comes with mozilla-build has issues so it’s necessary to point your path to a standalone version
* the tinderbox cvs_root uses private key access so we have to alter symbolstore.py to check for an environment variable of SRCSRV_ROOT which will be set in the tinder-config.pl file to the public :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot.
* the reason that %fnchdir% wasn’t working in my VS was because the srcsrv.dll it was using was an earlier version. once I copied the version from WinDBG over to the VS devenv folder, it worked. Still don’t know where %fnchdir% came from (googling it only turns up myself) but I am glad it’s working now and hopefully VS2008 express comes with this newer version – otherwise the documentation will be instructing people to do all sorts of extra work
* the last piece of the puzzle – Why Doesn’t the Code Show Up After Downloading? – turns out there’s a little checkbox in the options for debugging – something about requiring the exact file match…uncheck that and VOILA! Source Server worked in Visual Studio!!!

This is awesome. I am so thrilled that when the two bugs are resolved, downloading a nightly and debugging it should be really really easy!

Time to update some screenshots 🙂

So in order to get the current version of nightly builds to work for me, I had to add a srcsrv.ini file in the same place as the srcsrv.dll and devenv.exe – on my computer this is C:Program FilesMicrosoft Visual Studio 8Common7IDE

In that srcsrv.ini the only lines needed are:

[variables]

MYSERVER=:pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot

The reason for this is that anything in your local srcsrv.ini will override what’s in the pdb file. In the current situation, the pdb files for the nightly debug builds have MYSERVER=:ext:ffxbld@cvs.mozilla.org:/cvsroot since that is what the computer they were built on used. That cvspath does not work without a key though, so it is no good to the average user of source indexed builds.

The second tweak is still making sure that the code is being located properly once it’s downloaded. There is a way to change your registry to alter where Visual Studio looks for its cache of source code. I tried this and it worked but I’m not sure it was necessary. It’s all still a bit of a grey area.

However, the silver lining? The patch does work – with the tweaks which are pretty simple – so source indexed builds exists and hopefully some people will start using them and familiarizing themselves with source server. In the long run, the more people using it, the more people who will be able to hack on it.

Thanks especially to this article which helped tonight as I tried to find the right combination of settings.

Now it’s time to go write some things into the documentation.

So the fix worked and now the Mac/Linux |make buildsymbols| functionality is working again. As well, the nightly debug build from last night had source server indexing.

I downloaded the windows nightly to test it – in both WinDBG and Visual Studio 2005.

All looks good on VStudio – the symbols download and then when I try to break debugging I get this:
“This is great!” I think to myself and I happily hit “Run” several times to the various prompts for cvs commands.

Then…NO Source code can be found anywhere. Why? Well, it didn’t download with that cvs command. See how it’s got “:ext:ffxbld@cvs.mozilla.org:/cvsroot”? Well that doesn’t get me any code, what it does get it timeouts and errors like this.

So now what? I was able to run the command with :pserver:anonymous@cvs-mirror.mozilla.org:/cvsroot and pull the code files to their default location – which by the way is not anywhere you would find it by accident. Here’s what I found out about the location that SourceServer puts your code by default:

You may be wondering where Visual Studio puts the source server download cache. The default location is C:Documents and SettingsUsernameLocal SettingsApplication DataSourceServer. This is great because with proper security in place only logged-in users can see that directory.

http://msdn2.microsoft.com/en-us/magazine/cc163563.aspx

So I ran the command in that directory and when VStudio is done asking me over and over again about running cvs commands – I do get the source file I checked out appearing in my VStudio solution.

What now? I don’t know if this is something that needs to be changed in the mozilla code or if this is now about doing local changes with a srcsrv.ini file. Hopefully I will get some good advice about this soon so that I can demo it tomorrow without too much hacking and with a little bit of authority even 🙂