Client API Commit function - How to tell what failed

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
anobleperson
Posts: 6
Joined: Mon Sep 11, 2006 5:55 pm

Client API Commit function - How to tell what failed

Post by anobleperson » Tue Sep 12, 2006 8:54 pm

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)

Beth
Posts: 8550
Joined: Wed Jun 21, 2006 8:24 pm
Location: SourceGear
Contact:

Post by Beth » Wed Sep 13, 2006 7:22 am

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.

anobleperson
Posts: 6
Joined: Mon Sep 11, 2006 5:55 pm

Post by anobleperson » Wed Sep 13, 2006 10:43 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?

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Thu Sep 14, 2006 10:26 am

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:

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)));
	}
}
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.
Last edited by ian_sg on Thu Sep 14, 2006 10:27 am, edited 1 time in total.
Ian Olsen
SourceGear

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Thu Sep 14, 2006 10:27 am

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
Jeff Clausius
SourceGear

ian_sg
Posts: 787
Joined: Wed May 04, 2005 10:55 am
Location: SourceGear
Contact:

Post by ian_sg » Thu Sep 14, 2006 10:28 am

Heh, looks like Jeff and my responses collided. At least we gave the same answer! :wink:
Ian Olsen
SourceGear

anobleperson
Posts: 6
Joined: Mon Sep 11, 2006 5:55 pm

Post by anobleperson » Thu Sep 14, 2006 5:59 pm

Sounds like I should ask more questions so that you two can race some more and we can start taking bets on who'll answer first :)

Thanks for the quick replies, I'll update our code accordingly.

anobleperson
Posts: 6
Joined: Mon Sep 11, 2006 5:55 pm

Post by anobleperson » Tue Oct 10, 2006 11:17 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.

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Wed Oct 11, 2006 2:57 pm

ash:

If you don't care what is on disk, what if you used OverwriteWorkingCopy for the MergeType?
Jeff Clausius
SourceGear

anobleperson
Posts: 6
Joined: Mon Sep 11, 2006 5:55 pm

Post by anobleperson » Wed Oct 11, 2006 4:33 pm

Hi Jeff,
We've tried that, but it doesn't seem to want to override the file. Everything looks like it succeeded, but the file doesn't get overwritten with the newer one. That's why we started trying to figure out if the file was in a "needs merge" state.

cheers,
ash.

jclausius
Posts: 3706
Joined: Tue Dec 16, 2003 1:17 pm
Location: SourceGear
Contact:

Post by jclausius » Thu Oct 12, 2006 8:07 am

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. ?
Jeff Clausius
SourceGear

Locked