Collabnet Subversion Edge vs. Trac!

My team uses both Subversion and Trac, accessed through Apache, in its daily routine. Having read about CollabNet Subversion Edge (CSE from now on), a Subversion Server plus a nice management console, I was eager to try it but also a bit wary, since as any experienced sysadmin (not that I'm one of those) will tell you: "Change is good, you go first!".
Two things were troubling me: the embedded Apache server and Python 2.5 that CSE uses and enforces, but the one that brought havoc to my setup was the second.
I downloaded the setup, run it, and a second instance of Apache appeared in my Apache Monitor, green as an emerald! So far so good, I fired up the admin console of CSE and it was great, simple to use, complete also with some nice graphs depicting your SVN Server usage.
Next I checked up how my Trac was, and all I could get was a 500 Http Error while establishing the connection to my old Apache Server.
Time to check the error log, from which I recoiled in horror:

Fri Aug 20 08:47:33 2010] [error] make_obcallback: could not import mod_python.apache.\n

[Fri Aug 20 08:47:33 2010] [error] make_obcallback: Python path being used "['C:\\\\programmi\\\\python25\\\\lib\\\\site-packages', 'C:\\\\WINDOWS\\\\system32\\\\python25.zip', '', 'C:\\\\Programmi\\\\Apache Group\\\\Apache2\\\\bin']".

[Fri Aug 20 08:47:33 2010] [error] get_interpreter: no interpreter callback found.

[Fri Aug 20 08:47:33 2010] [error] [client 10.0.30.87] python_handler: Can't get/create interpreter.

So, to make a long story short, the Python 2.5 installation embedded in CSE folder conflicted with my system-wide Python installation and I couldn't find I way to reconcile the two. As far as I could understand, I could have redirected the python-path stored in the registry to my installation, but I would have lost the possibility of using CSE's ViewVC, the repository viewer: not a great loss, since Trac supplies a more than adequate substitute. What troubled me more was the maintainability of the solution: perhaps, at every (automatic) update of CSE, I had to repeat the same procedure of modifing the registry. At the end of the day, I uninistalled CSE, even if I consider it a worthwhile solution for the ease of configuration that brings to a Subversion installation.

Security warnings and NTFS ADS

Since Windows XP Service Pack 2, after downloading a file from the internet and running it, you have probably see a message box in this form:


The solution to get rid for good of this warning is to clear the check box or to open the properties of the file and unblock it:

If you have multiple files to unblock, you can use the streams.exe utility, by SysInternals.
What's happening behind the scenes? Since NT 3.51, NTFS has the possibility to store data into the so-called ADS or Alternative Data Streams, alternative containers of information associated to files. A file has a main stream called $DATA where its information is stored, but multiple streams can be created in the form file:stream. The information contained in a stream can be shown by opening a command line and using the command more:

more < file:stream

In the case of the downloaded executables, Windows adds a stream named zone.identifier, that contains the following information:
[ZoneTransfer]
ZoneId = 3

When ZoneId gets a value of 3, it means that the file was downloaded from the internet zone.

C++/CLI: the debugger can't hit any breakpoint

I'm extending a pure C++ solution using C++/CLI one with VS2008: it's a dll that gets invoked by our main program. For debugging purposes, in the same solution I have a separate project that links to the public interface of the DLL. Nice and easy, right? Yes, until I added the /CLR switch to the compiler command line; from that moment on, I was unable to debug the DLL, since VS couldn't reach the breakpoints I set, showing them as hollow circles with the yellow alert sign superimposed and informing me that no source code could be found. The precise error was:

"Breakpoint will not currently be hit. There is no source code available for the current location"

To make a (quite) long story short, the problem was in the settings of the debugger: you have to set the debugger in mixed mode in the project of the exe calling the dll.

Visual Studio 2008 error "C2471: cannot update program database"

Having converted a Visual Studio 2005 C++ solution to Visual Studio 2008, while regenerating it for the first time I got a bunch of "C2471: cannot update program database" (in italian: "C2471: impossibile aggiornare il database di programma") errors. Ouch... At first I tried installing the Microsoft hotfix but for unknown reason the setup refused to work, then I found this blog post by Loren Heiny, where he writes about a workaround he found. Perhaps the solution is even simpler: just restart Visual Studio 2008 and regenerate the project. Why? Oh well, the only hypothesis I could think of is that, immediately after a solution conversion, VC++ 2008 keeps some files opened and is not able to update them.
Have fun!