Can't check out file that isn't checked out by anyone

1c3 · Post by **1c3** » Thu Jul 07, 2005 1:03 pm

Hi All,

I wonder if anybody else is having this problem. I can't check out a file that isn't checked out by either myself or anybody else. This also means I can't rename / delete it. This is what I'm getting in the message pane:

[07/07/2005 19:37:29] Checking out file $/xxx/xxx/xxx/v 2.0.0/Engine/Engine.csproj
[07/07/2005 19:37:34] Check out failed for $/xxx/xxx/xxx/v 2.0.0/Engine/Engine.csproj: You already have the file checked out.
[07/07/2005 19:37:34] Check out failed for $/xxx/xxx/xxx/v 2.0.0/Engine/Engine.csproj: You already have the file checked out.

Anybody know why this is happening?

And I'm sorry, because I wouldn't normally do this, but I'm going to engage in a little of what I hope will be constructive feedback. I am *SO* sick of Vault at the moment. We've just spent the money to upgrade from 2.something to 3.0.7 and to be honest it's been an exercise in utter pointlessness and frustration for all concerned:

(1) The server is *unbelievably* slow.

Check-out on a single file can take anywhere between 5 and 15 seconds (the number of files is basically irrelevant). Yes, that's right, for one file. One file!!! On a server that's basically idling and with virtually zero network traffic. Vault was never the quickest SCM system in the world, but now it's just painful. I *cannot believe* that this product was allowed out the door by the Sourcegear QA team with these appalling performance problems. It simply encourages people to check out whole folders in one go because it's so irritating now to check out files as you're working.

Now I have spoken to a tech support advisor about this, and am assured that this will be fixed in 3.1.0, which should hopefully be available in the next couple of months... so here's hoping.

(2) The client is.... well, basically it's pretty much identical to the 2.x version we had before.

At least from a user's perspective there's virtually no difference, apart from some small improvements to the "Add Files" dialog. So, remind me why we upgraded again please?

(3) And now it's just behaving oddly

I don't have this file checked out. Nobody has it checked out. Why can't I check it out? What's going on?

I've even tried deleting my local copy, getting the latest version (which worked) and checking out, but I still get the same error. I've restarted my Vault client, and I'm still getting the same error. What really is annoying the living daylights out of me is that Vault reports the file as not being checked out in the main window, it just gives me this ridiculous error when I try to check the file out.

And yes, I do have check out rights on the folder. I created the file in question myself, and I've just added a load of new files in a subfolder.

Anyway, rant over. I'd be extremely grateful for any help anyone can offer.

Many thanks,

1c3

lbauer · Post by **lbauer** » Thu Jul 07, 2005 1:41 pm

Anybody know why this is happening?

It's possible the file really is checked out. Are you using the IDE client or the GUI Client? Sometimes the client cache files can get out of sync with the tree and have incorrect information about the state of the tree. If your GUI client doesn't show the file is checked out, you might ask another user to login from their machine to see if their view shows the file is checked out. The Vault Admin tool will also show the checkout in the Undo Checkout tab.

(1) The server is *unbelievably* slow.

Regular database maintenance is very important, especially if you are checking out entire folders, etc. Vault 3.1 will have performance improvements, but you still need to do maintenance.
http://support.sourcegear.com/viewtopic.php?t=2924

This user was greatly helped by running maintenance:
http://support.sourcegear.com/viewtopic.php?t=4197

So, remind me why we upgraded again please?

There are a number of new features and bug fixes in Vault 3.0:
http://support.sourcegear.com/viewtopic.php?t=2368

We've been working with a customer offline on similar issues (maybe your company?) There were questions about running the maintenance. We'll make sure those get answered and hopefully, Vault will work to your satisfaction again.

lbauer · Post by **lbauer** » Thu Jul 07, 2005 1:52 pm

By the way, Vault 3.1 is currently in Beta 3. It's stable and fully supported by SourceGear.

You may want consider upgrading sooner rather than later:

http://support.sourcegear.com/viewtopic.php?t=4217

Guest · Post by **Guest** » Fri Jul 22, 2005 4:50 am

OK

We performed all the maintenance processes you suggested and it made no differences. So we have upgraded to version 3.1 (release) and the check in/out problems have seemed to resolve themselves - thanks. However the application is still really slow.

We have had to turm off the folder security for the short term while we look into this, otherwise the software is practically unusable.

We have 7026 folders and 61681 files, with a tree size of 2.49 GB. We need to turn back on security asap do you hav any more suggestions?

Post by **jclausius** » Fri Jul 22, 2005 6:57 am

I'm currently addressing this issue, and should have something to report back shortly.

Bart Read · Post by **Bart Read** » Wed Jul 27, 2005 7:20 am

Hi there,

I'm very sorry to have to report that the check out issue still exists in Vault 3.1.0. Two of us here have experience the problem today where Vault reports, "You already have the file checked out", but the client shows that the file isn't checked out (and reports it as renegade if it's been modified) - note that we are not using the VS.NET integration.

The only way around this that we've found is to get an admin to undo the check out for us, then check out ourselves (merging changes if necessary), and check back in.

This issue was affecting us really badly in 3.0.7, and caused a great deal of hassle for everyone using Vault, so we'd really appreciate a proper fix for it.

Many thanks,

======================
Bart Read
Software Engineer
Red Gate Software Ltd
======================

Post by **jclausius** » Wed Jul 27, 2005 8:38 am

Bart:

We do want to get to the bottom of this. I'm trying to gather intelligence on the situation.

1) Has the performance issue gone away? My understanding is that this was resolved with a hot fix. Is this true?

2) Can you describe your security settings? What are your default security rights? What do your group / user rights look like?

3) It was mentioned you had folder security disabled for a while. No issues to report during this time?

4) Can you breifly describe the how problem occurs (with timing)?

- Do you checkout file(s) or checkout at the folder level.
- Seems to be working but after X minutes, a refresh occurs and the checkout disappears.
- Do you have a server log in Debug mode and can isolate your user log entries the time at which one of the checkouts disappear?

5) Do you lose ALL your checked out items, your checked out items in a particular folder and sub folder, your checked out items in a folder, but not sub folder, or only a particular file you've checked out - other files checked out in the same folder are OK.

Modified Post July 27 @ 11:08 CDT - Added item #5

Post by **jclausius** » Mon Aug 01, 2005 8:52 am

Bart:

I have a Vault 3.1.1 pre-release which might help solve some of the problems. Is there anyone we can talk to about a server upgrade?

Nahum · Post by **Nahum** » Sun Aug 07, 2005 5:18 pm

A couple of my users have been getting exactly the same problem that has been described on this thread with respect to checkouts. I have found that it can be simply resolved (whenever it happens) by deleting their checkout list cache file and vola they see the file as checked out to themselves or someone else - whatever the situation.

Strangely though the problem also seems to be office dependent. We had a bit of a shuffle here; 3 vault users all moved from room A to room B and immediatly they all started having problems. One of those users have subsequently moved to room C and has never had the problem since. They all are using Vault thru Visual Studio. Something dodgy happening with the network connection maybe? I understand that with each office move they also changed which routers they were going thru.

lbauer · Post by **lbauer** » Mon Aug 08, 2005 7:31 am

Strangely though the problem also seems to be office dependent. We had a bit of a shuffle here; 3 vault users all moved from room A to room B and immediatly they all started having problems. One of those users have subsequently moved to room C and has never had the problem since. They all are using Vault thru Visual Studio. Something dodgy happening with the network connection maybe? I understand that with each office move they also changed which routers they were going thru.

That is strange. The Geographic factor? Probably hard to reproduce.

We did make some changes to checkout in Vault 3.1.1, which was officially released last week. Let us know if this helps with the checkout issue.

Guest · Post by **Guest** » Tue Aug 09, 2005 10:01 pm

lbauer wrote:That is strange. The Geographic factor? Probably hard to reproduce.

We did make some changes to checkout in Vault 3.1.1, which was officially released last week. Let us know if this helps with the checkout issue.

Of the two guys left in the room, one has move to working at home and has reported that all problems to have ceased. It could well be that we have a dodgy router that's dropping packets or something which Vault isn't noticing and thus corrupting it's cached data.

I have scheduled to upgrade our 3.07 server to 3.1.1 tuesday/wednesday next week. I'll let you know how it goes.

One thing that concerns me though is that our DB is approx 22GB in size and in noting the warning about long upgrade times for large DBs I grabbed a backup and stuck it on a spare development machine to test the upgrading. It took 2.5 minutes, the vault server app was on a seperate machine (mine). I installed a 3.1.1 client and all seemed to work fine and dandy. The machine is a AMD64 3.2ghz with 1gb ram running 64bit WinXP and SQL Server (not sure if the 64bit or 32bit version thoughof SQL Server). What do you consider a large DB?

Nahum.

lbauer · Post by **lbauer** » Wed Aug 10, 2005 10:23 am

It's not so much the size of the database as the complexity of the upgrade. We run some database integrity checks before upgrading. If anything needs to be fixed, we run the fixes first.

So we want to give users a heads up that things may take a while. In many cases, the upgrade goes quickly, even with a large database.

lbauer · Post by **lbauer** » Wed Aug 10, 2005 10:37 am

That being said . . . you may want to check your schema version to be sure the DB actually upgraded, since 3.1.1 clients can connect to 3.0.7 servers and their databases.

use sgvault
go
select * from tblschemaversions
go

The schema version for Vault 3.1.1 is 3.1.1.1

Nahum · Post by **Nahum** » Wed Aug 10, 2005 7:04 pm

The upgraded backup reports 3.1.1.1 as the schemaversion - so it worked successfully.

I noticed that our dual proc xeon P4 > 2ghz server holding our live vaultdb took 40 minutes to upgrade from 2.x to 3.0x compared to my test upgrade which was quicker than a click of my fingers on the AMD machine. Could the act of backing up then restoring for the test server actually be doing some tidying up with the vault db or anything else which could speed it up?

I know tuesday/wednesday next week anyway.

shenderson · Post by **shenderson** » Fri Aug 12, 2005 7:40 am

We are running 3.0.7 here at Match.com and it's killing us. We are experiencing this exact problem along with one where when a user checks a file in Vault thinks that the file is unchanged so everything gets rolled back and our developers lose their changes.

We are upgrading to 3.1.1 today. Did upgrading to 3.1.1 fix your problem?

SourceGear Support

Can't check out file that isn't checked out by anyone

Can't check out file that isn't checked out by anyone

Still there in 3.1.0 unfortunately

same problem