VSPTree is alive!

I've been using Windows 8 for the last couple of months and have been having a great time with it. It's Windows 7 with a nice flat UI, much faster I/O. Stability is the same, and pretty much have never opened a metro app. I'm not even sure how to use those correctly. The new Start Menu is just a very big start menu to me.

Anyway I digress, I needed to profile something and went with the usual suspects. CodeAnalyst, Got no data. AQTime, failed to launch the exe. Very Sleepy, worked but no hierarchical call graph. Tried to resurrect VSPTree with the VS2010 profiler and I got a driver not allowed error.

Oh well. Some digging around and I found Remote Tools for Visual Studio 2012.

So I took a little time and updated VSPTree to work with it, and added some minor usability updates. It's not the best application in the world, but sometimes it's handy just to have it.

VSPTree 0.5 : Now with Windows 8 64 bit support. Here.

Conditionals in Property Sheets

I've since moved to using property sheets exclusively instead of wfMake and it's been going well. A bit more more typing but I like the fact that I can edit a bunch of includes and not have to regenerate the vcproj/vcxproj. The most time consuming part was going through all the projects and setting the right macros everywhere. But you only have to do it once.

It's one place to update everything and can be syntax highlighted and formatted quite neatly.

You end up with something like this. This is only an excerpt, the whole thing is quite huge. You can then string your macros any way you like. The fanciest bit of this is the conditionals at the top that I use because some sln's that include these projects are sometimes in different places, and there was no other way I could think of to correctly set the path.

  
  
    
      
        $(ProjectDir)..\..\..\
      
    
    
      
        $(ProjectDir)..\..\..\
      
    
    
      
        $(SolutionDir)
      
    
  
  
    
    
      WF_DEBUG;
      _DEBUG
    

    
      WF_RELEASE;
      NDEBUG
    

    
      WF_FINAL;
      NDEBUG
    

    
    
      WF_PC32;
      WIN32;
      _CRT_SECURE_NO_WARNINGS;
      $(FORCED_ENVARS)
    

    
      $(WF_DEBUG);
      $(PC32_PREPROCESSOR);
      __PLACEMENT_NEW_INLINE
    


  

Pre-commit goodness

This solution was used to solve programmers frequently accidentally committing debug executables into SVN. On developer machines you rarely see this issue because all the debug libs exist, but a level designer or artist will frequently run into the problem and will have no idea what the problem is, and someone will have to take a look at it and figure out what in the world is going on. Then the doh! moment happens and someone has to recompile and commit that.

The precommit hook also show an example of how to deny committing certain files like .argb and thumb.db

The solution is simple enough. Add a precommit hook that scans all the exe's for debug libs. This method uses Dependency Walker by Steve Miller.

So far I've tested it on rather large commits with 20 exe's and it doesn't take more than 20 - 30 seconds to complete. Server is running a i7-960 for reference.

cd /d %~dp0
SETLOCAL ENABLEDELAYEDEXPANSION
SET REPOS=%1
SET TXN=%2

SET PATH=E:\svn;E:\bin;E:\depends

svnlook changed %REPOS% -t %TXN% > E:\temp\svnlook%TXN%

grep -E "A.+(.argb)" E:\temp\svnlook%TXN%

if "%ERRORLEVEL%"=="0" (
 echo Do not commit ARGB files! >&2
 goto :error
) 

grep -E "A.+(thumbs.db)" E:\temp\svnlook%TXN%

if "%ERRORLEVEL%"=="0" (
 echo Do not commit thumbs.db! >&2
 goto :error
)

grep -P -o "(?<=\w\s\s\s).+\.exe" E:\temp\svnlook%TXN% > E:\temp\svnlook%TXN%_exegrep

for /f "tokens=1 delims=¶" %%f IN (E:\temp\svnlook%TXN%_exegrep) DO (
 svnlook cat %REPOS% -t %TXN% "%%f" > E:\temp\temp
 depends.exe /c /of:E:\temp\dep.txt E:\temp\temp
 grep -E "QT.+D4.DLL" E:\temp\dep.txt
 if "!ERRORLEVEL!"=="0" (
  echo Do not commit Debug executables! %%f is in debug>&2
  goto :error
 )
)

del E:\temp\svnlook%TXN%
del E:\temp\svnlook%TXN%_exegrep
exit 0

:error
del E:\temp\svnlook%TXN%
del E:\temp\svnlook%TXN%_exegrep
exit 1

Saving tortoiseGit password

Took me a little while to find this, so I thought I would immortalize it here.

Apparently you need to save a file called _netrc in %USERPROFILE%

So a quick little batch file :

@echo off
SET /P HOST=What is the hostname i.e github.com?
SET /P USERNAME=What is your username?
SET /P PASSWORD=What is your password?

echo machine %HOST% login %USERNAME% password %PASSWORD% > "%USERPROFILE%\_netrc"

Crappy documentation? Internet to the rescue

So through some amazing series of events, I broke the TeamCity installation.

Things weren't building. I thought it might be a bug, so maybe I'll try a newer version. The newer version needed an upgrade to the database so I said OK, but I made sure to back up first of course.

Lo and behold the new version did solve the old problem, but it presented a host of new ones! Basically made it unusable. Of course this was a beta build, but hey beta is the new GMC nowadays right? WRONG!

Oh well, time to uninstall and go back to the backup. Cue the 30 minutes I spend trying to figure out how in the world do I restore this backup!

The manual says :

Just do this!

maintainDB[cmd|sh] restore -F <TeamCity backup file name>

Error : config is not empty. Ok I'll delete that then.

run again

Error : system is not empty. Ok I'll empty that too!

run again.

Needs a target!

Wuh? That's the "Restoring Data from Backup to Another Database" instruction not the standard restore.

But no. It doesn't work. Ok, scrounge around a bit more....

Hallelujah.

Turns out you need to copy the database.hsqldb.properties.dist out of the config directory in your backup zip first. Give that as the -T database.hsqldb.properties.dist

And then everything gets restored. Then it gives you some instruction that says, you have to copy that file into system\buildserver.properties.

Did I? Nope. Did the restore work? Yes.

Bad documentation is bad.