我主要从事Windows开发。我们使用Mantis和Subversion进行开发，但它们并未集成在一起，实际上它们位于不同的服务器上。

我对将两者整合在一起做了一些谷歌搜索，并发现了这篇文章。看起来很有趣。

我想知道是否有人在做或者已经做过，经验如何。如果我们有其他解决方案，我也很想知道！

谢谢！

解决方案

我遇到了scmbug。看起来它将像螳螂之类的东西与Subversion之类的东西联系起来。

我们已经使用scmbug了很长时间，将SVN链接到Bugzilla。效果很好，直到最近我们升级到Bugzilla 3.2为止，这破坏了集成。当新版本的SCM工具问世时，scmbug团队需要一些时间才能赶上，这是可以理解的。

我们按照我们链接中的步骤进行操作，唯一的区别是，在Windows上，我们具有post-commit.bat。如果向下滚动，则有人发布示例。我们对其进行了修改，以便将更改后的文件记录下来，然后由谁将其更改为批处理文件的简单漏洞。我们曾经尝试过将差异包含在内，但是由于某些签入的大小，这样做很快是一个坏主意，这一点很明显。

它工作得非常好，现在我真的很高兴我必须将所有Sourcesafe的内容移到各个地方...

我将螳螂与SVN一起使用。就像该链接所说的一样，尽管我将regexp放在了提交后的过程中，所以如果提交消息不相关，它就不会尝试更新该错误，这会使非错误更新的提交的响应速度更快。

我的螳螂安装也位于另一台服务器上。我使用curl来调用Mantis 1.1.6中的php方法。

将其放在post-commit.cmd挂钩中(我们需要下载草莓perl并从中获取perl.exe和perl510.dll，而无需其他)

c:\tools\perl c:\tools\mantis_urlencode.pl %1 %2  > c:\temp\postcommit_mantis.txt
if %ERRORLEVEL% NEQ 0 exit /b 0

c:\tools\curl -s -d user=svn -d @c:\temp\postcommit_mantis.txt http://swi-sgi-l-web1.ingrnet.com/mantis/core/checkincurl.php

并将其放在mantis_urlencode.pl中

$url = `svnlook log -r $ARGV[1] $ARGV[0]`;

# check the string contains the matching regexp, 
# quit if it doesn't so we don't waste time contacting the webserver
# this is the g_source_control_regexp value in mantis.

exit 1 if not $url =~ /\b(?:bug|issue|mantis)\s*[#]{0,1}(\d+)\b/i;

$url = $url . "\n" . `svnlook dirs-changed -r $ARGV[1] $ARGV[0]`;

#urlencode the string
$url =~ s/([^\w\-\.\@])/ eq " "?"+":  sprintf("%%%2.2x",ord())/eg;

print "log=$url";

exit 0;

如果要从VSS迁移，则有很多脚本，包括我在Codeplex上编写的脚本。

一切正常，我们一直在使用它，并且它足够快而不会注意到它。只需键入" Fixed Mantis＃1234"，它即可解决该错误并向其添加错误提示。该脚本还会在bugnote中添加已修改的目录(我尝试显示已更改的文件，但太多的内容不便于理解)