I've got TotroiseSVN installed and have a majority of my repositories checking in and out from C:\subversion\ and a couple checking in and out from a network share (I forgot about this when I originally posted this question).

This means that I don't have a "subversion" server per-se.

How do I integrate TortoiseSVN and Fogbugz?

Edit: inserted italics

+9  A: 
+1  A: 

Does this url help ?

That requires you to have a subversion server, which I don't. I installed TortoiseSVN to my local computer, and use it to create repositories on my C and Z(network share) drives. So, as far as I can tell, I don't have a full blown Subversion server installed. TortoiseSVN just handles everything
+2  A: 

Why can't you simply install a subversion server? If you download VisualSVN Server, which is free, you get a http server for your source code and can thus use the FogBugz scripts for integrating the two.

The reason I'm asking is because all scripts and documentation so far assumes you have the server, client-side scripts are too new for FogBugz to have templates for them so you're pretty much left to your own devices on that.

Lasse V. Karlsen

I am not sure I follow you. Do you have the repositories on the network or on your C:\ drive? According to two of your posts, you have both, or neither, or one of them or...

You can not get VisualSVN or Apache to safely serve repositories from a network share. Since you originally said you had the repositories on your C:\ drive, that's what you get advice for. If you have a different setup, you need to tell us about that.

If you have the repositories on your local harddisk, I would install VisualSVN, or integrate it into Apache. VisualSVN can run fine alongside Apache so if you go that route you only have to install it. Your existing repositories can also just be copied into the repository root directory of VisualSVN and you're up and running.

I am unsure why that big post here is labelled as incomplete, as it details the steps necessary to set up a hook script to inform FogBugz about the new revisions linked to the cases, which should be what the incomplete message says it doesn't do. Is that not working?

Lasse V. Karlsen
I've got a bunch of repositories on my C:\ drive, and several on a network share. Point being, I have Tortoise, I don't have Subversion, How can I still make it work?
My solution is incomplete because it only works one way. The way it is designed to work, when you commit a change, you enter a fogbugz case number. Then, when viewing the subversion log, the case number will be a clickable link to fogbugz.
When viewing a fogbugz case on the fogbugz website, there is supposed to be a list of subversion checkins that addressed that case.Right now my solutions will create links in the subversion(tortoise) logs, but not on the fogbugz pages.

Does this url help ?

That requires you to have a subversion server, which I do not.

I am assuming fogzbugs and subversion are on the same machine. Right ?
Did you try using the file:///path/to/subversion whenever you need to enter the url in that document ?

+1  A: 

The problem is that FogBugz will link to a web page, and file:///etc is not a web page. To get integration two ways, you need a web server for your subversion repository. Either set up Apache or something else that can host those things the proper way.

Lasse V. Karlsen
+12  A: 

I've been investigating this issue and have managed to get it working. There are a couple of minor problems but they can be worked-around.

There are 3 distinct parts to this problem, as follows:

  1. The TortoiseSVN part - getting TortoiseSVN to insert the Bugid and hyperlink in the svn log

  2. The FogBugz part - getting FogBugz to insert the SVN info and corresponding links

  3. The WebSVN part - ensuring the links from FogBugz actually work

Instructions for part 1 are in another answer, although it actually does more than required. The stuff about the hooks is actually for part 2, and as is pointed out - it doesn't work "out of the box"

Just to confirm, we are looking at using TortoiseSVN WITHOUT an SVN server (ie. file-based repositories)

I'm accessing the repositories using UNC paths, but it also works for local drives or mapped drives.

All of this works with TortoiseSVN v1.5.3 and SVN Server v1.5.2 (You need to install SVN Server because part 2 needs svnlook.exe which is in the server package. You don't actually configure it to work as an SVN Server) It may even be possible to just copy svnlook.exe from another computer and put it somewhere in your path.

Part 1 - TortoiseSVN

Creating the TortoiseSVN properties is all that is required in order to get the links in the SVN log.

Previous instructions work fine, I'll quote them here for convenience:

Configure the Properties

  1. Right click on the root directory of the checked out project you want to work with.

  2. Select "TortoiseSVN -> Properties"

  3. Add five property value pairs by clicking "New..." and inserting the following in "Property Name" and "Property Value" respectively: (make sure you tick "Apply property recursively" for each one)

    bugtraq:label    BugzID:
    bugtraq:message  BugzID: %BUGID%
    bugtraq:number   true
    bugtraq:url      http://[your fogbugz URL here]/default.asp?%BUGID%
    bugtraq:warnifnoissue   false
  4. Click "OK"

As Jeff says, you'll need to do that for each working copy, so follow his instructions for migrating the properties.

That's it. TortoiseSVN will now add a link to the corresponding FogBugz bugID when you commit. If that's all you want, you can stop here.

Part 2 - FogBugz

For this to work we need to set up the hook scripts. Basically the batch file is called after each commit, and this in turn calls the VBS script which does the submission to FogBugz. The VBS script actually works fine in this situation so we don't need to modify it.

The problem is that the batch file is written to work as a server hook, but we need a client hook.

SVN server calls the post-commit hook with these parameters:

<repository-path> <revision>

TortoiseSVN calls the post-commit hook with these parameters:

<affected-files> <depth> <messagefile> <revision> <error> <working-copy-path>

So that's why it doesn't work - the parameters are wrong. We need to amend the batch file so it passes the correct parameters to the VBS script.

You'll notice that TSVN doesn't pass the repository path, which is a problem, but it does work in the following circumstances:

  • The repository name and working copy name are the same
  • You do the commit at the root of the working copy, not a subfolder.

I'm going to see if I can fix this problem and will post back here if I do.

Here's my amended batch file which does work (please excuse the excessive comments...)

You'll need to set the hook and repository directories to match your setup.

rem @echo off
rem   SubVersion -> FogBugz post-commit hook file
rem   Put this into the Hooks directory in your subversion repository
rem   along with the logBugDataSVN.vbs file

rem   TSVN calls this with args <PATH> <DEPTH> <MESSAGEFILE> <REVISION> <ERROR> <CWD>
rem   The ones we're interested in are <REVISION> and <CWD> which are %4 and %6



rem   debugging
rem echo %1 %2 %3 %4 %5 %6 > c:\temp\test.txt

rem   Set Hooks directory location (no trailing slash)
set HooksDir=\\myserver\svn\hooks

rem   Set Repo Root location (ie. the directory containing all the repos)
rem   (no trailing slash)
set RepoRoot=\\myserver\svn

rem   Build full repo location
set Repo=%RepoRoot%\%~n6

rem   debugging
rem echo %Repo% >> c:\temp\test.txt

rem   Grab the last two digits of the revision number
rem   and append them to the log of svn changes
rem   to avoid simultaneous commit scenarios causing overwrites
set ChangeFileSuffix=%~4
set LogSvnChangeFile=svn%ChangeFileSuffix:~-2,2%.txt

set LogBugDataScript=logBugDataSVN.vbs
set ScriptCommand=cscript

rem   Could remove the need for svnlook on the client since TSVN 
rem   provides as parameters the info we need to call the script.
rem   However, it's in a slightly different format than the script is expecting
rem   for parsing, therefore we would have to amend the script too, so I won't bother.
rem @echo on
svnlook changed -r %4 %Repo% > %temp%\%LogSvnChangeFile%
svnlook log -r %4 %Repo% | %ScriptCommand% %HooksDir%\%LogBugDataScript% %4 %temp%\%LogSvnChangeFile% %~n6

del %temp%\%LogSvnChangeFile%

I'm going to assume the repositories are at \\myserver\svn\ and working copies are all under `C:\Projects\

  1. Go into your FogBugz account and click Extras -> Configure Source Control Integration

  2. Download the VBScript file for Subversion (don't bother with the batch file)

  3. Create a folder to store the hook scripts. I put it in the same folder as my repositories. eg. \\myserver\svn\hooks\

  4. Rename VBscript to remove the .safe at the end of the filename.

  5. Save my version of the batch file in your hooks directory, as post-commit-tsvn.bat

  6. Right click on any directory.

  7. Select "TortoiseSVN > Settings" (in the right click menu from the last step)

  8. Select "Hook Scripts"

  9. Click "Add" and set the properties as follows:

    • Hook Type: Post-Commit Hook

    • Working Copy Path: C:\Projects (or whatever your root directory for all of your projects is.)

    • Command Line To Execute: \\myserver\svn\hooks\post-commit-tsvn.bat (this needs to point to wherever you put your hooks directory in step 3)

    • Tick "Wait for the script to finish"

  10. Click OK twice.

Next time you commit and enter a Bugid, it will be submitted to FogBugz. The links won't work but at least the revision info is there and you can manually look up the log in TortoiseSVN.

NOTE: You'll notice that the repository root is hard-coded into the batch file. As a result, if you check out from repositories that don't have the same root (eg. one on local drive and one on network) then you'll need to use 2 batch files and 2 corresponding entries under Hook Scripts in the TSVN settings. The way to do this would be to have 2 separate Working Copy trees - one for each repository root.

Part 3 - WebSVN

Errr, I haven't done this :-)

From reading the WebSVN docs, it seems that WebSVN doesn't actually integrate with the SVN server, it just behaves like any other SVN client but presents a web interface. In theory then it should work fine with a file-based repository. I haven't tried it though.

Andy Madge