Client displays and GetLatest bugs

Rachel Lavoie · Post by **Rachel Lavoie** » Thu Jan 20, 2005 11:18 am

Hi,

We use Vault 3.0.1 and we setup the client to a VSS style (check-out check-in).

Here are some anoying glitch our programs got when using Vault;

Problem 1
=======
- File is renegate
- Do a get latest on the file
- the local file is updated, but the program don't compile.
- We compare the local and the network file, we realise that the last lines that where added on the network are added in the local file 10 lines later in the file (at the wrong place).
- Add to do a get latest overwrite to fix the problem.

This is particularely dangerous if the programs still compile even if the lines aren't added at the same place.

Problem 2
=======
Even if we use the "use CRC to compare files" option, a lot of files are getting the renegate status sporadically even if those files are identical (network VS local). To remove the renegate status, programmers have to do regularely some GetLatestVersion. They spend times on it and they start to be frustrated of doing it repetively.

We have this problem from the start and I investigated a lot to get the source of the problem. At first it was one of our program that where modifying the date of the files, we correct the problem but the bugs still sticking, but less bad. Now I have some indices that makes me think it is Visual Studio, but not for sure.

Anyway, whatever is the source, if you check the CRC of the content of the file, there is no excuse to pop a Renegate status if files are identical and the dif app tells too that they are identical.

Problem 3
=======
- File get Old status (without apparently logical cause)
- Do Get Latest on it
- operation failed (on msg window)
- Get Latest Overwrite (sometimes its ok from here)
- the file get the "Needs Merge" status
- Do again a Get Latest Overwrite
- the status get backs to normal.

In all step, a compare files showed here that they where identical. This pattern showed up since we upgraded to the 3.01 version.

Problem 4
=======
We have a lot of problem too about the "Read Only" status of files. I couldn't note for you a specific pattern about this problem, but sometimes files don't get writtable when we check out or don't get Read Only when we check in. This is kind of dangerous...

Ending Notes
========

I activated the log in Vault so that when a bug occur, I can send it to you. But I couldn't find the log file in the temp directory. Where is this log file and what is it's name format?

From the start, I apreciated a lot the service you gave me in the support, even when I posted in the standard support (not the gold). Every time the maximum delay I got is less than a day, your service is really exellent and a lot of user seems to appreciate it. It's one of the major argument that leads us to buy your product.

Safe your respect, the only think that tire me and the programmers it's all those little glitches, they scares us because we don't feel that the product will take care of the source. Trying to get the causes is painfull because there is not a lot of indices and most anoying, it cost us time that we don't have.

I stay at your service to get as much as information needed about it and I hope that these bugs will be catch asap.

Thanks again for your kindness and your good support,
Regards,

Rachel Lavoie · Post by **Rachel Lavoie** » Thu Jan 20, 2005 11:21 am

I forgot another problem (sorry).

Sometimes a file gets a "Merged" status and stick with it, even if we close and reopen the client, check out, check in or do a get latest operation.

How do I get rid of it?

Thanks again.

dan · Post by **dan** » Thu Jan 20, 2005 1:15 pm

One overall question: Do you do most of your work with the GUI client or the IDE client?

Anytime you get a merge that you don't think works right, be sure to save off the files at their state and send them to us. The 3 files we need are:

1. The version currently in the repository
2. The version in the working folder
3. The "baseline" version. This is the latest version on the client that was retrieved by Vault, or put another way, the server version that you started at when editing the local working file.

We have having a 3.0.2 coming out this week that fixed a problem that only existed in the GUI merge tool and sometimes caused the behavior described in Problem 1. Send me email if you would like to get an advanced copy of 3.0.2, so you can check this out.
-------
For Problem 2, are the files in question larger than the maximum specified in Tools->Option->Local Files? Files larger than that value do not have the CRCs computed, for performance reasons, but it is easy to turn that off.

For this problem as well, send us the working file and the repository file so we can try to reproduce it.

Also, you might check whether this happens to all users for the same file, or just one user, as that might help localize the problem.
-------
For Prob 3 - are you saying a file is Old but there is not a newer version on the server? Also, what error message is being displayed?

For this, the log file would be probably be pretty helpful.

-----------
Problem 4

Is this the IDE client or the Vault GUI client? Are the files status messed up after successful checkouts or checkins, or is it always after an error?

-----------
The log file should be in your %TEMP% folder - type in %TEMP% in a windows explorer, and it should take you to the right folder. It should be called VaultGUIClient.txt or something similiar.

It sounds like most of the problems are related to the "Get" command, so be sure log only that command - logging "all" dumps way too much info to dredge through, and it will be easier to debug that way. Send me any log info you have when things like this happen, and we'll see if we can find out what is going on.

Rachel Lavoie · Post by **Rachel Lavoie** » Thu Jan 27, 2005 5:30 pm

Hi,
thanks for your answer...

One overall question: Do you do most of your work with the GUI client or the IDE client?

We use GUI client because we have a standard version of the VC that doesn't support IDE source control.

Anytime you get a merge that you don't think works right, be sure to save off the files at their state and send them to us. The 3 files we need are:

1. The version currently in the repository
2. The version in the working folder
3. The "baseline" version. This is the latest version on the client that was retrieved by Vault, or put another way, the server version that you started at when editing the local working file.

I cannot do that. Not that I don't want to, It's because our code is highly secured and the company politic is to not send any code byte outside de company.

We have having a 3.0.2 coming out this week that fixed a problem that only existed in the GUI merge tool and sometimes caused the behavior described in Problem 1. Send me email if you would like to get an advanced copy of 3.0.2, so you can check this out.

We installed it yesterday, so I will watch to see if it fixed the problem.

For Problem 2, are the files in question larger than the maximum specified in Tools->Option->Local Files? Files larger than that value do not have the CRCs computed, for performance reasons, but it is easy to turn that off.

The option of not checking files larger than X is off, so CRC is supposed to be calculated on EVERY files and all programmers have the same configuration.

For this problem as well, send us the working file and the repository file so we can try to reproduce it.

I'm really sorry do disapoint you again but I cannot...

Also, you might check whether this happens to all users for the same file, or just one user, as that might help localize the problem.

I will check if one file get the satus renegate, if every one have the same status for this file. I'll give you an answer about that asap.

For Prob 3 - are you saying a file is Old but there is not a newer version on the server? Also, what error message is being displayed?
For this, the log file would be probably be pretty helpful.

The file gets the status Old, as the version on the server where greater than the local file. But when we compare the server file and the local file, both files are identical.
It's the same pattern with sporadic renegate files. They gets renegate, but when we compare them with Diff (yours or any Diff tool not made by you) their content are identical.

The next time I'll catch it, I'll get messages and log file for you.

Is this the IDE client or the Vault GUI client? Are the files status messed up after successful checkouts or checkins, or is it always after an error?

As I said earlier, It's on the GUI client. I don't know if they where errors or not, I'll give you an answer about that asap.

The log file should be in your %TEMP% folder - type in %TEMP% in a windows explorer, and it should take you to the right folder. It should be called VaultGUIClient.txt or something similiar.

Thanks!

It sounds like most of the problems are related to the "Get" command, so be sure log only that command - logging "all" dumps way too much info to dredge through, and it will be easier to debug that way. Send me any log info you have when things like this happen, and we'll see if we can find out what is going on.

Thanks a lot. I'll do so.

Have a nice end of day and a great week-end...