TFS 2010 gated check-in using TortoiseSvn over SvnBridge

I have the configuration in the above title. I am using the TFS gated check-in feature which works fine if i use the TFS tools to check in my changes.

A review of my understanding of the way it works:

my changes are intercepted by the gated check in and put in a shelveset. The shelveset is pulled down by the build server, built, unit tests run, and gets checked in with NO CI appended to the end of the check in comment. When all that is done, a prompt to reconcile the workspace occurs.

Using TortoiseSvn:

i can commit code and update code just fine as long as I do not have gated check-ins set up.

With gated check-ins set up, the TFS server sends back a 500 error (see exception below) and the tortoiseSvn client shows the error labeled below, though the check in process continues. The build server builds, runs tests, and commits the code with no problem but this is pretty annoying and would be hard to convince other developers to use because you get the error on commit and then have to perform an update on the code to get the changes actually committed by the build server.

Thanks for any ideas or help.

TortoiseSvn Error

Error: Commit failed (details follow):

Error: Server sent unexpected return value (500 Internal Server Error) in response to

Error: MERGE request for '/mil-tfsprd-01/Inst%20Trading%20Support/Source/Main/ODS/Eliminator/Eliminator

Stack trace from SoapException

System.Web.Services.Protocols.SoapException: Your check-in has been placed into shelveset Gated_2011-09-22_10.26.49.8403;US\RPieper and submitted for validation by build definition \Inst Trading Support\Eliminator.
   at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
   at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
   at CodePlex.TfsLibrary.RepositoryWebSvc.Repository.CheckIn(String workspaceName, String ownerName, String[] serverItems, Changeset info, CheckinNotificationInfo checkinNotificationInfo, CheckinOptions checkinOptions, Failure[]& failures)
   at CodePlex.TfsLibrary.ObjectModel.SourceControlService.<>c__DisplayClass4.<Commit>b__3()
   at CodePlex.TfsLibrary.ObjectModel.SourceControlService.WrapWebException[T](WrapWebExceptionDelegate`1 function)
   at CodePlex.TfsLibrary.ObjectModel.SourceControlService.Commit(String tfsUrl, ICredentials credentials, String workspaceName, String comment, IEnumerable`1 serverItems)
   at SvnBridge.SourceControl.TFSSourceControlProvider.<>c__DisplayClass18.<MergeActivity>b__17(Activity activity)
   at SvnBridge.SourceControl.ActivityRepository.Use(String activityId, Action`1 action)
   at SvnBridge.SourceControl.TFSSourceControlProvider.MergeActivity(String activityId)
   at SvnBridge.Proxies.RemotingInvocation.Proceed()
   at SvnBridge.Proxies.TracingInterceptor.Invoke(IInvocation invocation)
   at SvnBridge.Proxies.RemotingInvocation.Proceed()
   at SvnBridge.Proxies.RetryOnExceptionsInterceptor`1.Invoke(IInvocation invocation)
   at SvnBridge.Proxies.RemotingInvocation.Proceed()
   at SvnBridge.Proxies.ProxyFactory.RemotingProxy.Invoke(IMessage msg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at SvnBridge.SourceControl.TFSSourceControlProvider.MergeActivity(String activityId)开发者_如何学JAVA
   at SvnBridge.Handlers.MergeHandler.Handle(IHttpContext context, TFSSourceControlProvider sourceControlProvider)
   at SvnBridge.Handlers.RequestHandlerBase.Handle(IHttpContext context, IPathParser pathParser, NetworkCredential credentials)
   at SvnBridge.Net.HttpContextDispatcher.Dispatch(IHttpContext connection)
   at SvnBridge.Net.Listener.Process(TcpClient tcpClient)
   at SvnBridge.Net.Listener.Accept(IAsyncResult asyncResult)

---

SvnBridge doesn't support gated checkin - as you note, you'll fall back to this behavior.

If you're only using SvnBridge for Tortoise, you might want to check out the TFS integration into Windows Explorer instead which provides native access to TFS instead of through a bridge. It's available in the Team Foundation Server Power Tools.