Error checking in a changed file

If you are having a problem using Vault, post a message here.

Moderator: SourceGear

Post Reply
Chris

Error checking in a changed file

Post by Chris » Tue Apr 06, 2004 11:12 pm

This is the second time this has happened, the last time it happened we "fixed" it by just deleting the existing file and re-adding it again, but this time we have history we would like to keep if possible (last time the file was brand new).

The problem is we have a PRG file checked out and edited, but when the person tries to check it in they get a message saying "Failure" and the client log says "Server unavailable for transaction end".

Here is the log from the server (debug level):

Code: Select all

----7/04/2004 3:00:21 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	GetRepositories returned: Success
----7/04/2004 3:00:29 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	BeginTx beginning transaction
----7/04/2004 3:00:29 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	BeginTx returned:  Success
----7/04/2004 3:00:29 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	VaultServiceBase.VaultRequestCheckIn returned: Success
----7/04/2004 3:00:29 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	Uploading file.
----7/04/2004 3:00:30 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	VaultFileUpload.aspx encountered:  Success
----7/04/2004 3:00:30 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	Ending transaction
----7/04/2004 3:00:30 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	VaultServiceBase.VaultResponseCheckIn returned: Failure
----7/04/2004 3:00:30 PM     mherman--192.168.0.36(192.168.0.36)--SSL Disabled
	EndTxFailure
We have tried setting the "DontUseChunkedHTTP" thing on the client, but I don't think that has any impact on this issue because the log says the upload was successful.

Any help would be appreciated.

Is there a third level of logging we can turn on? "...VaultResponseCheckIn returned: Failure" isn't very useful really.

Chris.

Chris

Post by Chris » Tue Apr 06, 2004 11:13 pm

Also it is vault 2.0.1 and the Client is WinXP SP1, the server is Windows 2000 Server SP3

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Wed Apr 07, 2004 8:42 am

Does the problem appear to be related to the user, the machine, or the file?

Try checking in the file from another machine with a different user. If it files, it points to the file being the problem.

If the same user can check it the exact same file on a different machine, then it might be something about the state of cache files on the first machine.

If a different user can check in the file on the same machine, it might be something with the user's options.

Chris

Post by Chris » Wed Apr 07, 2004 4:57 pm

Dan,

The problem has arisen on 2 seperate users on 2 seperate files, the person can undo checkout, but still nobody else could check it in on other PCs. It definitely seems to be the file itself.

Any ideas?

Chris.

Chris

Post by Chris » Wed Apr 07, 2004 5:53 pm

Also if it helps here is the profile trace from the SQL Server at the time of the attempted checkin.

I tried executing the last storedproc, and it seemed to return the correct number of deltas (I assume 1 per previous version?) - it returned 3 deltas, the file is at version 4 but one of those versiosn is a branch.

(I have blanked out the SQL username that is used)
Attachments
vaultprofile.txt
This is the profile log (it didn't paste too well into the forum)
(1.67 KiB) Downloaded 893 times

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

Post by jclausius » Thu Apr 08, 2004 8:42 am

chris:

can i ask some questions here...

1) can you look inside your vault.config file on the server. do you have an xml element for <fulltext>? if so, what is the value?

2) what is the version of the file being checked in?

3) in your attachment, it looks like spgetdeltachainforfullfile is the last stored procedure call. there should be a call to dbo.spcheckinfile, but i do not see that call. can you verify the call is missing?
Jeff Clausius
SourceGear

Chris

Post by Chris » Thu Apr 08, 2004 9:00 am

Answers:

1. The element is there and the contents is <FullText>50</FullText>

2. The version in the repository is 4, consisting of:
Ver 1: Created
Ver 2: Checked In
Ver 3: Checked In
Ver 4: Branched from another location
(About 10 labels after that)
The change I am attempting to checkin will make it version 5.

3. dbo.spcheckinfile is not called, immediately after the rollback it runs spgetuserrepositorylastchange. (In the trace log I attached I only included from the beginning to the end of the transaction, if you feel any else of it might prove useful I can send a more complete one - but the rest seemed just to be getrepositroyinfo sort of things.)

Chris.

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

Post by jclausius » Thu Apr 08, 2004 9:34 am

ok. can you e-mail me (click the link at the bottom)? we'll try to get you a special server which is spitting out more info during a checkin operation
Jeff Clausius
SourceGear

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

Post by jclausius » Thu Apr 08, 2004 9:56 am

oops..

i forgot to ask one other thing -

4. how big is the file? what is the setting for the maxRequestLength attribute for the httpRuntime element in web.config?
Jeff Clausius
SourceGear

Chris

Post by Chris » Fri Apr 09, 2004 8:22 am

Jeff,

That setting is 153600.

Sending email just as soon as I register...

Chris.

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Fri Apr 16, 2004 8:23 am

Working with Chris to track this down, the following was found.

1. His Vault server was set to use impersonation with a specially created domain account,
2. The domain account did not have permission to log on locally, and so didn't have a folder in c:\Documents and Settings
3. The server would throw an exception whenever it would call System.IO.Path.GetTempFileName(), which would attempt to create a temp file in c:\Documents and Settings\Account.Domain\Local Settings\Temp

Giving the domain permission to log on locally resolved the problem.

Post Reply