Exception during checkin - working folder already in use

Mar 14, 2008 at 4:40 PM
When using SVNBridge to check in to my Codeplex project, it throws an exception. When I choose debug to look at the stack, I see the following error about a working folder already in use. Not sure what my next steps could be to resolve the issue, any ideas? I also use TortoiseSVN on this same computer for my job but it connects to a different repository. However, I use C:\ as my workspace for both. Perhaps I have answered my own question? :-) Looking for tips here of course.

Here's the full error detail:

System.Web.Services.Protocols.SoapException was unhandled
Message="The working folder C:\\ is already in use by the workspace MYPC-1;SND\\adammil_cp on computer MYPC-1."
Source="System.Web.Services"
Actor=""
Lang=""
Node=""
Role=""
StackTrace:
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.UpdateWorkspace(String oldWorkspaceName, String ownerName, Workspace newWorkspace)
at CodePlex.TfsLibrary.ObjectModel.SourceControlService.AddWorkspaceMapping(String tfsUrl, ICredentials credentials, String workspaceName, String serverPath, String localPath)
at SvnBridge.SourceControl.TFSSourceControlProvider.MakeActivity(String activityId)
at SvnBridge.Handlers.MkActivityHandler.Handle(IHttpContext context, ISourceControlProvider sourceControlProvider)
at SvnBridge.Handlers.HttpContextHandlerBase.Handle(IHttpContext context, String tfsUrl)
at SvnBridge.Net.HttpContextDispatcher.Dispatch(IHttpContext connection)
at SvnBridge.Net.Listener.Process(TcpClient tcpClient)
at SvnBridge.Net.Listener.Accept(IAsyncResult asyncResult)
at System.Net.LazyAsyncResult.Complete(IntPtr userToken)
at System.Net.ContextAwareResult.CompleteCallback(Object state)
at System.Threading.ExecutionContext.runTryCode(Object userData)
at System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Net.ContextAwareResult.Complete(IntPtr userToken)
at System.Net.LazyAsyncResult.ProtectedInvokeCallback(Object result, IntPtr userToken)
at System.Net.Sockets.BaseOverlappedAsyncResult.CompletionPortCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* nativeOverlapped)
at System.Threading._IOCompletionCallback.PerformIOCompletionCallback(UInt32 errorCode, UInt32 numBytes, NativeOverlapped* pOVERLAP)
Mar 18, 2008 at 10:51 PM
Hmm, this is an interesting one. SvnBridge creates a temporary workspace during check-in, then removes it once the check-in is finished. It sets "C:\" as the working folder for the temporary workspace, which in your case is conflicting with one of your workspaces created using Team Explorer.

SvnBridge doesn't actually use the working folder for the temporary workspace, so we could use any path and so maybe we need to have it use a pathname that will ensure uniqueness.

An immediate workaround to your problem is probably either moving your working folder for your Team Explorer workspace to another location, or modifying the constant in SvnBridge to a different path location.
Mar 19, 2008 at 2:47 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Mar 19, 2008 at 11:07 PM
This was moved to workitem:9703, but was immediately marked as Closed and set to Low priority. Since it is an actual crash bug I think it should be set to higher than Low priority because that means something fairly serious is going on in the code. Also, I don't think it should be closed while the issue still happens and there is no clear understanding of the cause to be able to fix it.

I added more information to the work item, but if I can help more, please let me know.

Any thoughts on this?
Mar 20, 2008 at 3:55 AM
Sorry for the confusion, it was closed because it has been fixed in changeset 16901. Ayende forgot to mention the changeset number in the closing comments for the work item.
Mar 20, 2008 at 3:18 PM
Wow, that's fantastic! Thank you so much for the fix and for the follow-up!

Svnbridge is definitely one of the most useful codeplex projects and one of my personal favorites. Thank you for all your hard work!