Remote version does not match file history

christian · Post by **christian** » Thu Jan 27, 2005 4:32 am

I'm rather concerned with what I'm seeing (running vs 3.0.0.2752 client and server).
I have an automated build that checks-out, modifies then checks-in a number of files.
I've just run such a build and then looked at the file list as it appears in the main window in the Vault client.
I see a status on the files that I know were modified by the build as "More Recent". The remote version shows up as a version behind the local.
For example one such file shows up as local vs=2 and remote vs=1.

This is cause for concern as this suggests that the changes to the local file were not checked into Vault. However, this is not the case as proved by looking at the history of this file. The file history shows a check-in and a latest version=2. So while a query against the file history shows vs=2 the remote vs column in file list menu shows vs=1.

What the heck is going on here! It is really critical I can get this resolved asap as we're moving off of source safe this week to Vault in preparation for a release into production the end of this week!

Thanks
Christian

Post by **jeremy_sg** » Thu Jan 27, 2005 8:17 am

Most likely, the file or folder was pinned back to an old version. Is that the case?

christian · Post by **christian** » Thu Jan 27, 2005 8:26 am

jeremy_sg wrote:Most likely, the file or folder was pinned back to an old version. Is that the case?

Hi Jeremy,
No pins in the files I'm afraid. The Vault database was pretty much virgin before running the build. The Vault database was created by importing a source-safe database that was created to include only last version of the files in the working directory for source safe.
Christian

dan · Post by **dan** » Thu Jan 27, 2005 8:32 am

If there is another Vault client running other than the Vault GUI client that does checkins by the same user, the Vault GUI client will be using the same client side cache files as the other client, but it only invokes a server refresh once every 10 minutes or so (or whatever you set it to).

So, it will show the local file as being a more recent version, until you do a refresh on the GUI client, and that is when it knows there is a new version on the server too. It is just an oddity of running two clients on the same machine by the same user.

Also, if you haven't yet distributed Vault widely to your team, I would recommend downloading the most recent 3.0.2 version and using it, so you don't have to do upgrades later.

christian · Post by **christian** » Thu Jan 27, 2005 8:37 am

Ok Dan, that does seem to be what I'm doing so I'll checked this out :-)

christian · Post by **christian** » Thu Jan 27, 2005 8:44 am

Have another question now you've mentioned client side cached files. Should I be deleting these if I restore an older version of sgvault database?
Christian

dan · Post by **dan** » Thu Jan 27, 2005 9:00 am

Yes, that would be a good idea, since the cache could contain versions of files that do not exist in the server.

christian · Post by **christian** » Thu Jan 27, 2005 9:01 am

Thought as much.

christian · Post by **christian** » Thu Jan 27, 2005 12:22 pm

Dan,
I rolled back the database to a position immediately prior to running the build, deleted cached files in app data directory and deleted the working directory.

I've just run the build and checked that the Vault gui *is* reporting the correct remote version. So I think before, either the GUI hadn't refreshed or the client was referencing cached files pertaining to the wrong database backup.

Thanks for the help
Christian

dan · Post by **dan** » Thu Jan 27, 2005 12:44 pm

Good - I'm glad that is resolved for you