Client API Commit function - How to tell what failed
Moderator: SourceGear
-
- Posts: 6
- Joined: Mon Sep 11, 2006 5:55 pm
Client API Commit function - How to tell what failed
As part of our build system we check-in our version number file. Sometimes the commit returns false, and the commit doesn't happen. Is there anyway to tell what the failure was?
The command we call is:
bSuccess = _ci.Commit(csicForCommit, false, false);
I *think* that it is failing because the file gets in a funny state sometimes and says it needs a merge, but its hard to tell because there is no message or exception thrown.
Client Information
Vault Client Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2032
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Total Physical Memory: 1.5 GB
Time Zone: (GMT+10:00) Hobart
Server Information
Vault Server Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2300
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 1.0
OS Version: 5.2.3790
Timezone: (GMT+10:00) Canberra, Melbourne, Sydney
SQL Version: Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
The command we call is:
bSuccess = _ci.Commit(csicForCommit, false, false);
I *think* that it is failing because the file gets in a funny state sometimes and says it needs a merge, but its hard to tell because there is no message or exception thrown.
Client Information
Vault Client Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2032
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Total Physical Memory: 1.5 GB
Time Zone: (GMT+10:00) Hobart
Server Information
Vault Server Version: 3.5.0.4741
.Net Framework Version: 1.1.4322.2300
Operating System: Microsoft(R) Windows(R) Server 2003, Standard Edition
Service Pack: 1.0
OS Version: 5.2.3790
Timezone: (GMT+10:00) Canberra, Melbourne, Sydney
SQL Version: Microsoft SQL Server 2000 - 8.00.2039 (Intel X86)
May 3 2005 23:18:38
Copyright (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 1)
What should give you what you need is placing the server into debug mode and then checking the Vault Server Log after a commit fails. To place the Vault Server into Debug mode, open the Vault Admin Tool and go to the Server Options tab. The second half of the window covers logging. Set the Log Level to Debug.
-
- Posts: 6
- Joined: Mon Sep 11, 2006 5:55 pm
Thanks for the quick response Beth. Next time I encounter the problem I will certainly turn the logs to default and see what I can find out.
What I'm really after is a way to recover from such a problem programmatically, so if I know what's gone wrong I can try and fix it without the build user ever knowing there was a problem. Is there any way to tell what happened from the APIs?
What I'm really after is a way to recover from such a problem programmatically, so if I know what's gone wrong I can try and fix it without the build user ever knowing there was a problem. Is there any way to tell what happened from the APIs?
Noble,
The ChangeSetItem objects contain failure information when commit returns false. Here's a snippet from the Vault client that gets failure information and emits a user-comprehensible message:
In a nutshell, you want to loop over the ChangeSetItemColl and check for a status code != VaultStatusCode.Success on each ChangeSetItem's Request.Response.Status. If it makes sense in your client, you can get the text for a status code using VaultConnection.GetSoapExceptionMessage.
The ChangeSetItem objects contain failure information when commit returns false. Here's a snippet from the Vault client that gets failure information and emits a user-comprehensible message:
Code: Select all
foreach (ChangeSetItem item in items)
{
if (item.Request.Response != null && item.Request.Response.Status != VaultStatusCode.Success)
{
EmitMessage(new ProgressMessageTransactionItemFailed(item.Request.ItemPath, String.Format(VaultConnection.GetSoapExceptionMessage(item.Request.Response.Status), item.Request.ItemPath)));
}
}
Last edited by ian_sg on Thu Sep 14, 2006 10:27 am, edited 1 time in total.
Ian Olsen
SourceGear
SourceGear
Take a look at your change sets after the failure. Each ChangeSetItem will have a VaultRequestItem. After BeginTx() and EndTx(), the Request will have a VaultResponseItem member. These members will have the corresponding failure for the commit - See VaultStatusCode for a list of valid error failures.
Also, I think you can ask your Vault Connection object to decipher the info with GetSoapExceptionMessage(int statusCode);
HTH
Also, I think you can ask your Vault Connection object to decipher the info with GetSoapExceptionMessage(int statusCode);
HTH
Jeff Clausius
SourceGear
SourceGear
-
- Posts: 6
- Joined: Mon Sep 11, 2006 5:55 pm
-
- Posts: 6
- Joined: Mon Sep 11, 2006 5:55 pm
Along the same lines, we now have a trickier problem. When we request a version by label, occasionally that file "needs merge", so it doesn't get the version we need it to get. I can find out programmatically that a file needs to be merged, but I can't figure out the calls to resolve that status programmatically.
I've been trying:
workingFolder.ResolveMergeStatus(vcFile);
The error I get back is that it can't find the baseline file in the version list. This may be because I'm trying to get a newer version than I've fetched before?
I can send you the whole function, but it's pretty much the same as the ProcessCommandGetLabel from the Command API.
cheers,
ash.
I've been trying:
workingFolder.ResolveMergeStatus(vcFile);
The error I get back is that it can't find the baseline file in the version list. This may be because I'm trying to get a newer version than I've fetched before?
I can send you the whole function, but it's pretty much the same as the ProcessCommandGetLabel from the Command API.
cheers,
ash.
-
- Posts: 6
- Joined: Mon Sep 11, 2006 5:55 pm
Using OverwriteWorkingCopy would be your best bet. What are the parameter values you are using with GetByLabel_GetData()?
Is Recursive set to true if this is a folder?
What is MergeType's value?
What about destinationDiskPath?
In regards to WorkingFolder::ResolveMergeStatus(), what are the properties of the VaultClientFile? Does it have a valid object ID, version, ObjVerID, path, etc. ?
Is Recursive set to true if this is a folder?
What is MergeType's value?
What about destinationDiskPath?
In regards to WorkingFolder::ResolveMergeStatus(), what are the properties of the VaultClientFile? Does it have a valid object ID, version, ObjVerID, path, etc. ?
Jeff Clausius
SourceGear
SourceGear