File status problem in Vault client

Igor.Samoylenko · Post by **Igor.Samoylenko** » Thu Sep 07, 2006 4:44 am

Hi,

We are having some strange problems with file status reported by Vault client on one developer's machine. Only one developer is affected by this and in over a year of using and administering Vault I did not see anything like this on any other machine (we have about 10 developers using Vault).

Anyway, the problem is that somehow this developer in question has got himself into a position when he has a number of files checked out and changed locally. But in Vault client the file status is shown as either checked in and renegade or checked out and needs merge.

Also, the local version number is wrong (it can be something like local 1 remote 5). This is strange because the only way to get to this in Vault as far as I can see it to get a version in file history, then take off read-only flag and modify it locally. The developer certainly did not do that.

This is presumably related to the problem with diff: just doing a straight diff of the problem files with the default options, the changes shown in the comparison are not correct. I.e. the file displayed as local working is not correct. If the file is checked in (by resolving merge status and checking it in), the diff in the history between the versions looks different (correct).

Other problems are: when using Vault client and Visul Studio at the same time and a file is checked out in Vault client, when you get back to VS it does not update the status even on get latest on the file (it si still shown as checked in). If I try to check out the file in VS, it says the file is already checked out by someone else.

I tried to delete local cache but it does not solve the problem: opening vault client, it recreates the cache and the problem with the file status is still there.

Is there a way to reset any local cache in Vault (last received version, dates ats)? We are happy to go through all the problem files and manually sort out each file and check them all into Vault. But then I would like to reset Vault client, get latest version and hopefully get back to normal. What can you suggest?

Beth · Post by **Beth** » Thu Sep 07, 2006 12:30 pm

All the issues listed just pertain to the one developer?

the problem is that somehow this developer in question has got himself into a position when he has a number of files checked out and changed locally. But in Vault client the file status is shown as either checked in and renegade or checked out and needs merge.

If he performs a refresh, the status remains the same? Is he checking out the files exclusively? You may wish to check out this article that has more information on statuses and the situations that cause certain ones.

Also, the local version number is wrong (it can be something like local 1 remote 5). This is strange because the only way to get to this in Vault as far as I can see it to get a version in file history, then take off read-only flag and modify it locally. The developer certainly did not do that.

What happens if the user performs a get latest? Is the local version being updated then? If not, then check out #3 in this article: http://support.sourcegear.com/viewtopic.php?t=562

This is presumably related to the problem with diff:

I think if we get the other pieces fixed, diff will be fine, so I'll come back to this.

Other problems are: when using Vault client and Visul Studio at the same time and a file is checked out in Vault client, when you get back to VS it does not update the status even on get latest on the file (it si still shown as checked in). If I try to check out the file in VS, it says the file is already checked out by someone else.

What happens if you perform a refresh in VS?

You may wish to set up client side logging on that user. More details can be found here: http://support.sourcegear.com/viewtopic.php?t=1534.[/code]

Igor.Samoylenko · Post by **Igor.Samoylenko** » Fri Sep 08, 2006 4:25 am

Thanks Beth.

Yes, it is specific to a single developer. I also haven't seen this problem before with anyone else. The checkouts are always exclusive (server is set to require exclusive locks). (Simple) refresh does not fix the problem.

I will have a look at the references you gave. I would like to understand myself what is going on a bit better before I come back to you.

Igor.Samoylenko · Post by **Igor.Samoylenko** » Fri Sep 08, 2006 5:00 am

I think I have narrowed the problem down to a very specific example:

There is a file that: a) the developer sees as checked in, status "Require merge", local version is 1, remote version is 9. However, if I do a search in my own Vault client, I can see this file is checked out by that developer.

Refresh does not help.

As far as local cache is concerned, the settings of the client Vault on the developer's machine are to use a single cache folder (instead of storing cache within working folders).

We tried to rename this cache folder. When opening Vault client after clearing cache, it starts off with displaying file status as "unknown". But then when it refreshes itself, it get back to the same situation as before.

So my question is: how, after removing local cache, Vault client determines the file checkin status and local version (and gets it wrong

)? Shouldn't the file status be "Unknown" until "Get latest version" is performed?

Beth · Post by **Beth** » Fri Sep 08, 2006 7:42 am

Did you have him change his working folder to somewhere else on his disk? It just seems like Vault is looking somewhere else than expected, so have him try changing his working folder and then perform a get latest.

If that doesn't work.....
The next thing I would think is that the bindings between the Vault and Visual Studio might not be quite right. You could have the one developer unbind his solution, and then reopen from source control. How he opens it will depend on the type of project it is. Here's more information: http://support.sourcegear.com/viewtopic.php?t=776

For web projects: http://support.sourcegear.com/viewtopic.php?t=5548

Igor.Samoylenko · Post by **Igor.Samoylenko** » Fri Sep 08, 2006 7:57 am

In my last reply I was actually referring to using Vault client directly not VS. This is what is most confusing: it is Vault itself that is confused about the status of the file not VS.

One of the first things I though of was that there are two or more folders in the repository have the same folder on the disk set as a working directory. That does not seem to be the case.

So what exactly does Vault client do when the local cache is not present? I.e. when I delete/rename the cache folder? Wouldn't it simply display the file status as "Unknown" until I use "GET latest version"? Or is it not that simple?

Also, where in cache does it store the file version? Is it in "state" bin file?

Beth · Post by **Beth** » Fri Sep 08, 2006 8:14 am

What versions of Vault and VS are you using?

Igor.Samoylenko · Post by **Igor.Samoylenko** » Fri Sep 08, 2006 8:15 am

3.1.0.3494 for both server and client

[Added]
VS .NET 2003

Igor.Samoylenko · Post by **Igor.Samoylenko** » Fri Sep 08, 2006 9:49 am

I have just tried to get the latest version on the problem file - it did not fix it. I tried both: "Attempt auto merge" and "do not modify, merge later".

It still says the status "Require merge", local version is wrong etc. I have also double checked that Vault is not showing the file is checked out on the developer's machine when I can see it is checked out by the developer from my machine.

Beth · Post by **Beth** » Fri Sep 08, 2006 10:51 am

And what operating system is the client using, the server, and the version of SQL server?

When you performed that last get, had he changed his working folder first?
Is the file listed as checked out in Visual Studio? If so, can he go ahead and get that checked in and any other files he may have out?

How long had he been working with Vault and VS before these issues showed up?

If you had already tried changing the working folder, then I think he needs to perform the unbind I suggested earlier in Visual Studio. Since it is only happening with one user, there is most likely either he is working on a very different set-up than everyone else, or his project isn't bound properly or something in the way he works with it is different, or if he was a recent install then something didn't go quite right in the install possibly due to something different in his environment or profile. In general, once a user has the IDE integration going, they should not be going into Vault nor to the files in the folders for any operations to prevent any mismanagement of files or binding problems. I mention this because that is often the case with many users.

Igor.Samoylenko · Post by **Igor.Samoylenko** » Fri Sep 08, 2006 11:06 am

Windows XP Prof, Windows 2000 Server and SQL Server 2000.

The working folder is set correctly (if I use open working folder). What do you mean by changing it? Change it to what?

The files are not listed as checked in either VS or Vault client.

He says it has been going on for a few months now.

I am not sure I understand why you are suggesting to re-bind VS. In this post I have been referring to the Vault client only not to VS. I.e. it is Vault client that does not display the status correctly etc not VS.

VS has also been open with the solution under source control but we have't used it. Using VS instead of the Vault client results in the same problems - the file is not shown as checked out, trying to check it out results in error "File is checked out by someone else ...". File status or version is not shown in VS.

Can you answer the questions I posted earlier in this post please (about local version, Vault's behaviour if there is no local cache etc)? I will then try to understand what is going wrong. So far, there isn't much I can do because Vault is a black box to me as far as those questions are concerned. I tried everything obvious so far.

Beth · Post by **Beth** » Mon Sep 11, 2006 3:02 pm

The working folder is set correctly (if I use open working folder). What do you mean by changing it? Change it to what?

I was suggesting the user make a new folder on their drive and change the working folder to that.

Once Vault is integrated with VS, then VS runs the show on how certain things will be done. There is the potential for messed up bindings if one is bouncing between which they will be using. I was under the impression from your first post that this integration was being used. Also, VS has a tendancy to insist on placing files where it wants them to be. Based on this, I suggested rebinding the project to ensure all the bindings were set.

When the local cache is deleted, Vault will recreate it.

We tried to rename this cache folder. When opening Vault client after clearing cache, it starts off with displaying file status as "unknown". But then when it refreshes itself, it get back to the same situation as before.

Did you perform a Get Latest?

the developer sees as checked in, status "Require merge",

Have you looked in the history on that file to see if something was captured to show that changes were made to that file after the other developer checked it out? One could have potentially performed an edit on that file without checking it out.

Igor.Samoylenko · Post by **Igor.Samoylenko** » Tue Sep 12, 2006 3:24 am

Yes, I tried to do a get latest on the file. It did not help - Vault was still showing the same status "Require Merge" etc.

The VS integration was used but now we are trying to get the Vault client to work not VS. I know VS runs the show and often changes the working directory especially for web apps and it is hard to control that. The point is, once it has set the working folder it does not change it. And you can get to it by using "Open working folder" in Vault client. The working folder seems correct.

I understand the file can be edited without being checked out etc. The problem is: I don't think the developer did it. Also, what about the file version? Why does it think the local version is 1 while the remote version is 5? This is what I was saying in one of the previous posts: you can go into file history, get version 1, take off read-only flag and modify the file. But this is too long-winded to happen by chance and the developer is telling me he did not do it intentionally.

He is saying he checked out the file (therefore getting the latest version locally), modified it and now somehow he founds himself in a situation when Vault does not recognise the file is checked out and gets the local version wrong etc.

I understand the cache is recreated but how does it determine the local version without knowing what it got last from Vault (i.e. without cache)? Also, what about the checkout status? How come he cannot see the file as checked out in his Vault client when I can see it in my Vault client (I cannot see how problems with working folder can cause this)? What do I need to do to fix that?

There are two many unknowns here and we can continue going around in circles forever. Can you specifically answer the following two questions for now:

1. How does Vault client determine the local file version? Specifically, how does do it when local cache is deleted and therefore as I understand it there is no way it can know that?

2. There is a file that is checked out by the developer in Vault but the developer himself cannot see it in his own Vault client. His Vault client does not show the file as checked out at all whilst I can see it being checked out by that developer in my Vault client and in Vault Admin. How can this happen and how do we fix it? At the moment, he had to uncheck "Require the file to be checked in before allowing check out" option the Vault settings as a workaround.

Beth · Post by **Beth** » Tue Sep 12, 2006 1:43 pm

1. How does Vault client determine the local file version? Specifically, how does do it when local cache is deleted and therefore as I understand it there is no way it can know that?

Here is an article on everything that is stored in the cache. http://support.sourcegear.com/viewtopic.php?t=6 The rest would be in the database Vault uses.

Without the cache, Vault doesn’t know what the file version is, and it will cause Vault to show an unknown status. Vault also doesn’t know if the cache is there or not. It just rebuilds it if it isn’t present when it needs to make use of it.

2. There is a file that is checked out by the developer in Vault but the developer himself cannot see it in his own Vault client. His Vault client does not show the file as checked out at all whilst I can see it being checked out by that developer in my Vault client and in Vault Admin. How can this happen and how do we fix it? At the moment, he had to uncheck "Require the file to be checked in before allowing check out" option the Vault settings as a workaround.

There are several things that could be causing this, and I won't really know until things are narrowed down.

Can you enable seeing the check out location? Go into the Vault client, Tools-Options-Files List Columns and it’s the last column option.

Could we get then a few screenshots showing the problem in action? We specifically would like to see the working folder path and the project path in the shots as well.

Can the developer see other people’s check-outs?

Is the file the developer working with in a branch or share?

I suggested client-side logging earlier. Is there any chance you could send a log file? If you prefer to not place additional information on the forum, you can either use the private option in the forum or send an email to beth at sourcegear.com.