Several successful command line checkouts were done without problems from the same folder. Then the wait for mutex problem surfaced.
Note: The GUI interface was concurrently active when running the script that issued the checkout.
vault client 2.0.1
vault CHECKOUT $/DIFR41/DIF2090.asm
returned:
<vault>
<error>
The working folder state information for C:\source\DIFR41 is incompatible with this version of Vault. Please choose a different working folder path. The specific compatibility exception was: Wait for the mutex was abandoned.
</error>
<exception>
System.Exception: The working folder state information for C:\source\DIFR41 is incompatible with this version of Vault. Please choose a different working folder path. The specific compatibility exception was: Wait for the mutex was abandoned.
at VaultClientOperationsLib.WorkingFolder.LoadState()
at VaultClientOperationsLib.WorkingFolder..ctor(ClientInstance ci, String diskFolderPath, Boolean makeBackups)
at VaultClientOperationsLib.ClientInstance.FindOrCreateWorkingFolder(String diskPath, Boolean makeBackups)
at VaultClientOperationsLib.ClientInstance.GetWorkingFolder(VaultClientFolder vcfolder)
at VaultClientOperationsLib.ClientInstance.UpdateKnownChanges_RefreshKnown(Boolean doNotify)
at VaultClientOperationsLib.ClientInstance.Refresh(Int64 knownServerRevision,
Boolean isRetry, VaultRepositoryDelta delta, Int64 returnedRevision)
at VaultClientOperationsLib.ClientInstance.SetActiveRepositoryID(Int32 id, String username, String uniqueRepositoryID, Boolean doRefresh, Boolean updateKnown
ChangesAll)
at VaultCmdLineClient.VaultCmdLineClient.Login(Boolean bAllowAuto, Boolean bSaveSession)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommandCheckout(ArrayList strItemArray)
at VaultCmdLineClient.VaultCmdLineClient.ProcessCommand(Args curArg)
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
</exception>
<result success="no" />
</vault>
command line exception: Wait for the mutex was abandoned.
Moderator: SourceGear
-
Don Thimsen
- Posts: 114
- Joined: Fri Mar 05, 2004 11:18 am
- Location: Raleigh, NC
-
Guest
Does it work if you close the GUI client and re-run the CLC command? I'm not sure what's holding the mutex (did you kill a previous version of Vault from the task manager?), but closing down all Vault instances should cause them to be released. If that fails, rebooting the client machine will guarantee no mutexes are held, but usually this isn't required.
-
Don Thimsen
- Posts: 114
- Joined: Fri Mar 05, 2004 11:18 am
- Location: Raleigh, NC
I did shutdown the GUI and the DOS session that issued the commands. After the problem started with the mutex, the CLC commands no longer worked. Checkouts would just hang. I rebooted the system and Vault started working normally.
One thing I forgot to check was whether the checkout could be done from the GUI after the mutex problem started.
The problem first appeared after I opened a DOS window, and executed a script that performed a set of checkout/checkins. I left the window open for about an hour, and then ran the script again. That's when the mutex problem started. Is there any reason that CLC processing would want to hold locks after completion of a command???
One other thought. I typically run the line commands and redirect the output to NUL to limit output from from the script. After the script runs, I can easily check the version/date-stamps on the GUI to see that the function completed successfully. However, it's possible that the problem mutex problem did start earlier, and the lock was held from the first script execution.
Thanks
One thing I forgot to check was whether the checkout could be done from the GUI after the mutex problem started.
The problem first appeared after I opened a DOS window, and executed a script that performed a set of checkout/checkins. I left the window open for about an hour, and then ran the script again. That's when the mutex problem started. Is there any reason that CLC processing would want to hold locks after completion of a command???
One other thought. I typically run the line commands and redirect the output to NUL to limit output from from the script. After the script runs, I can easily check the version/date-stamps on the GUI to see that the function completed successfully. However, it's possible that the problem mutex problem did start earlier, and the lock was held from the first script execution.
Thanks