Local File versions not reflecting remote file versions

trevord · Post by **trevord** » Mon Jan 15, 2007 1:42 am

We are using Vault 3.1.9. Occasionally local file display versions will not increment to reflect the remote server version. Eg. one developer checks out a file at version 20, makes changes, checks back in at 21. Another developer does a get latest on the file and only gets 20. Both local and remote versions on vault client display version 20.

Deleting cache files fixes problem but not desirable. Pinning then unpinning fixes problem. Is this a common problem, is there a solution, or a scenario to avoid causing this problem?

thanks, trevor

Beth · Post by **Beth** » Mon Jan 15, 2007 11:24 am

Does the second developer perform a refresh occasionally? There is an option available to setting Vault to auto-refresh.

If the user performs a refresh after someone else checks in changes, is any status given for the file?

trevord · Post by **trevord** » Mon Jan 15, 2007 5:52 pm

Yes, second developer performs a view refresh (if thats what you mean) but that doesnt fix the problem, the status of the file stays blank and both versions show 20, one less than the actual version, so vault thinks it has the latest version.

Beth · Post by **Beth** » Mon Jan 15, 2007 5:56 pm

Did you compare what the user was trying to check-in to what's actually in Vault? It could be a case of where somehow the file didn't make it into Vault.

Does this happen with more than one client?
Does this happen with other files as well? Could you try with a small test file?

trevord · Post by **trevord** » Mon Jan 15, 2007 6:02 pm

The definitely makes it into Vault. Other clients can see the newer version and deleting the cache on the problem client causes it to see the newer version.

It happens with more than one client, infrequently but a bit more often in the last few weeeks since we moved to 3.1.9.

It happens with various files.

It doesnt happen consistently, 99% of the time all is well. Chances are a test file wouldnt cause a problem. What else do you suggest, is this a known problem?

Beth · Post by **Beth** » Mon Jan 15, 2007 6:25 pm

This isn't an issue that I'm aware of. I think there's something else going on here. Would you like to send a client log from on of the problem clients and a Vault server log? You can send those to support at sourcegear.com (attn: Beth) and just reference this post. It will be easier for me to identify what's happening if you can just send the portions that cover from uploading the file version to the other client trying to get the latest version, or point out when they occurred.

To start client-side logging, just open the client and hold down the following keys on your keyboard: Control Alt Shift F12. More on the client logging can be found here: http://support.sourcegear.com/viewtopic.php?p=5375. If this wasn't running before, then you will want to go through the actions again with this running.

By default, the Vault Server log file is located in %WINDIR%\Temp\sgvault\sgvault.log. Sometimes, it is helpful to place your Vault server in Debug logging mode. You may do this in the Vault Admin Tool, on the Server Options tab. After you change the log level, you will need to restart the IIS service by choosing Start->Run... and typing iisreset and hitting OK. Once IIS has been restarted, you will see more verbose log messages.

trevord · Post by **trevord** » Mon Jan 15, 2007 6:27 pm

thanks beth, i'll try that and see how it goes

trevord · Post by **trevord** » Mon Jan 15, 2007 7:28 pm

We make use of the vault client api to do most of our source control operations from a custom app. This works well and does not seem directly related to the version problem we are experiencing. Checkins happen correctly and vault server increments version number, but something prevents the occasional client from seeing it. Ie. refresh in vault gui client shows previous version as latest.

Could api calls, such as FindFileRecursive, inadvertently invalidate/lock/corrupt the cache somehow, so that vault gui client is prevented from seeing newer versions of files?

Do api calls update and retrieve from the cache similar to vault client?

Do i need to perform additional operations through api like clearing part of the cache to ensure the correct latest version is retrieved?

Could there be conflicts between vault client, visual studio and a custom app making direct api calls so that the cache gets out of sync with the server repository?

Is the api itself loggable?

Any info or pointers to related info would be appreciated.

Beth · Post by **Beth** » Tue Jan 16, 2007 9:13 am

I'm checking into the API portion of your questions yet, but in the meantime, I'd like to verify if this behavior happens at all with just Vault alone. If the issue pops up with Vault alone, then that tells me what direction to take the troubleshooting. Have you run across that behavior with just Vault by itself?

Beth · Post by **Beth** » Tue Jan 16, 2007 9:39 am

In your custom app, you can turn on logging with:

SimpleLogger.Log.LogFilePath = "c:\\temp\\LogFile.txt";
SimpleLogger.Log.EnableClass("all");
SimpleLogger.Log.Enabled = true;

trevord · Post by **trevord** » Tue Jan 16, 2007 9:31 pm

We havent worked solely with vault gui client, so problem hasnt appeared in that scenario.

on further investigation, i think the problem may relate to the following code;

Code: Select all

vcFile = ci.TreeCache.Repository.Root.FindFileRecursive(fileName);
long latestVersion = vcFile.Version;
vcFile.Version = desiredVersion;
ci.GetByDisplayVersionToNonWorkingFolder(vcFile, MakeWritableType.MakeAllFilesWritable, SetFileTimeType.Current, vcFile.Parent.FullPath, destinationDir, null);
vcFile.Version = latestVersion;

This retrieves previous versions of a file for various tasks in our custom app eg. diffs.

The vcFile.Version appears to default to the latest version initially, then it remembers what it was last manually set to.

This works fine most of the time, but occasionally the problem manifests where a client gets stuck at a previous version and doesnt realise that the actual latest version of the file has moved on.

Is there a potential issue with manually setting the vcFile.Version? Should the cache still update correctly to reflect newer versions of the file as they are added, or could this code cause it to lose sync with the server? Is there a better way to get previous versions of a file?

thanks, trevor

Beth · Post by **Beth** » Wed Jan 17, 2007 11:17 am

Even though you don't work with the GUI, can you try it out just to confirm for me that it's not happening there as well? I will continue to look for more information on your issue with the API.

Beth · Post by **Beth** » Wed Jan 17, 2007 11:29 am

The issue appears to be that you are getting to a non-working folder and the get would need to go to a working folder in order for the cache to be updated. You should be able to compare what happens in each case.

Beth · Post by **Beth** » Wed Jan 17, 2007 1:25 pm

Sorry, misphrased that last post. What you may wish to do is look at the code for GetVersion in the command line client source code.

trevord · Post by **trevord** » Wed Jan 17, 2007 6:17 pm

I can see if it happens with the gui alone, but it could take a long time to manifest.

The issue appears to be that you are getting to a non-working folder and the get would need to go to a working folder in order for the cache to be updated.

I dont need the cache to be updated, its only a temporary get of a previous version so i can for eg. do a diff on 2 older files. Then i set the vcFile.Version back to its original version which should reflect the current workingfolder/cached version.

The cmdlineclient code for GetPreviousVersion does a similar thing when getting a non-working folder;

Code: Select all

vcFile = new VaultClientFile(_ci.TreeCache.Repository.Root.FindFileRecursive(treeObjectToRetrieve.FullPath));

// Set the version.
vcFile.Version = version;

if ( useWorkingFolder )
    getResponses = _ci.GetByDisplayVersion(vcFile, _args.MakeWritable, _args.SetFileTime, mt, null);
else
    getResponses = _ci.GetByDisplayVersionToNonWorkingFolder(vcFile, _args.MakeWritable, _args.SetFileTime, vcFile.Parent.FullPath, strDestFolder, null);

except the file.Version is not set back to the original version, which for me causes problems as the vcfile object remebers the version it was set to, which i suspect may be related to the problem we experience.