Overview
If you check in a file in SubVersion (SVN) and you don’t see any corresponding information appear in the FogBugz case (eg: check-in links stopped displaying), or the links from the FogBugz case pointing to SVN are not working, follow the troubleshooting steps from this article to identify the possible root cause.
Solution
SVN check-in information not getting to FogBugz
Verify Syntax
- Make sure you are using the correct syntax when referring to the case. Try BugzID:1 (if you have a case number 1)
Verify the trigger is running
- The post-commit script for Subversion has a line at the end that says
rm /var/tmp/$LOGSVNCHANGEFILE
(unix)del %temp%%logsvnfile%
(windows) - Add a # character to the beginning of this line so after the commit runs it does NOT delete the file in /var/tmp (or c:temp, c:windowstemp)
- Rerun a commit and validate the file is there.
- If the file is not there, try running the
post-commit
script directly (to make sure the problem is not svn failing to run it):- Go to your svn hooks directory
- Run
post-commit /path/to/svn/root/directory 1234
where the first argument is the root directory of your svn directory, and “1234” is a revision number containing a FogBugz case id. If anything goes wrong, you will see it on your console output.
Verify that logBugDataSVN is using the token parameter - FogBugz On-Demand
If your SVN repository is connecting to a FogBugz On-Demand instance, you need to pass a token parameter to be allowed to write into FogBugz cases.
- If you are using the logBugDataSVN downloaded from FogBugz look for the following line in the file:
http.Open "GET", BUGZ_URL & _ "/cvsSubmit.asp?ixBug=" & ixBug & "&sFile=" & URLEncode(sFile) & "&sRepo=" & sRepo & "&sPrev=" & sPrev & "&sNew=" & sNew & "&ixRepository=" & IXREPOSITORY, False
- Add to the command line the token parameter with a valid FogBugz token, right after the
csvSubmit.asp
. - The command line would look something like this if your token is
token=yoursecrettoken
:
http.Open "GET", BUGZ_URL & _ "/cvsSubmit.asp?token=yoursecrettoken&ixBug=" & ixBug & "&sFile=" & URLEncode(sFile) & "&sRepo=" & sRepo & "&sPrev=" & sPrev & "&sNew=" & sNew & "&ixRepository=" & IXREPOSITORY, False
Verify that logBugDataSVN is working
Verify if the logBugDataSVN
file is working. The easiest way to do this is to call it from the command line. (In the commands below, replace $REV with a valid revision number and $REPOS with the path to your repository.)
- Unix:
svnlook changed -r $REV $REPOS > /var/tmp/svnfile
svnlook log -r $REV $REPOS | perl /path/to/logBugDataSVN.pl $REV /var/tmp/svnfile $REPOS
- Windows:
svnlook changed -r $REV $REPOS > /var/tmp/svnfile
svnlook log -r $REV $REPOS | cscript /path/to/logBugDataSVN.vbs $REV /var/tmp/svnfile $REPOS
- If the above lines DID make an entry on your case, focus on the
post-commit
script. It’s likely thatsvnlook
is not in the scripts path, and you need to rewrite those lines in the script to use the full path to svnlook. Or the user that subversion runs as may not have permission to runcscript.exe
(on windows). - If the above lines DID NOT make an entry on your case,
logBugDataSVN
is failing. If you are using On Demand, or have an SSL FogBugz install, one of the most common reasons forlogBugDataSVN.pl
failing is the script cannot findwget
. At the top of the script, it may say $wget_path = `which wget`; and you should change this to$wget_path = "/actual/path/to/wget";
Also at the bottom of the script you should change the line that callssystem
to besystem("$wget_path --no-check-certificate '$url' -q -O /dev/null");
- If the above lines DID make an entry on your case, focus on the
Checkin info is getting into FogBugz, but the link back to WebSVN is not working
- Outside of FogBugz navigate to your site and make sure WebSVN is working on its own. Note the URLs that it is using and make sure you have set the appropriate pointers for your server. You can edit the URLs by editing your repo settings in Avatar Menu -> Source Control.
- If you are using an older version of FogBugz and you see %2F in the URLs where you should see “/”, change your Apache AllowEncodedSlashes configuration.