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:
The TortoiseSVN part - getting TortoiseSVN to insert the Bugid and hyperlink in the svn log
The FogBugz part - getting FogBugz to insert the SVN info and corresponding links
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
Right click on the root directory of the checked out project you want to work with.
Select "TortoiseSVN -> Properties"
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:message BugzID: %BUGID%
bugtraq:url http://[your fogbugz URL here]/default.asp?%BUGID%
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:
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 YOU NEED TO EDIT THE LINE WHICH SETS RepoRoot TO POINT AT THE DIRECTORY
rem THAT CONTAINS YOUR REPOSITORIES AND ALSO YOU MUST SET THE HOOKS DIRECTORY
rem echo %1 %2 %3 %4 %5 %6 > c:\temp\test.txt
rem Set Hooks directory location (no trailing slash)
rem Set Repo Root location (ie. the directory containing all the repos)
rem (no trailing slash)
rem Build full repo location
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
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
I'm going to assume the repositories are at
\\myserver\svn\ and working copies are all under `C:\Projects\
Go into your FogBugz account and click Extras -> Configure Source Control Integration
Download the VBScript file for Subversion (don't bother with the batch file)
Create a folder to store the hook scripts. I put it in the same folder as my repositories. eg.
Rename VBscript to remove the
.safe at the end of the filename.
Save my version of the batch file in your hooks directory, as
Right click on any directory.
Select "TortoiseSVN > Settings" (in the right click menu from the last step)
Select "Hook Scripts"
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"
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.