"Local version" number is wrong

bradw2k · Post by **bradw2k** » Tue Feb 21, 2006 11:16 am

I am seeing that the Local Version number in the GUI will not get updated when I perform a command-line getlabel. It doesn't matter if I do a -merge overwrite, or turn on CRC checking, or have the GUI open when running the command-line, or restart the GUI, or click "refresh" button in the GUI. The command does perform correctly and gets the version I want (e.g., version 126) but the GUI continues to say that the local version is the last version I got via the GUI (e.g., version 120).

Is there any way to "kick" or refresh the GUI to figure out what the local version actually is, besides actually doing a get operation in the GUI?

lbauer · Post by **lbauer** » Tue Feb 21, 2006 11:39 am

What version of Vault are you using? Does the status on the files change? If so, what is the status -- Unknown? Renegade? Are you using
-labelworking folder or -destpath in your command?

bradw2k · Post by **bradw2k** » Tue Feb 21, 2006 12:13 pm

I'm using 3.1.5 (3546). Here are the steps to reproduce:

1) I have a file that is currently on version 126. I label it "mylabel". So now label "mylabel" is on version 126.

2) In the GUI, I get version 120. GUI now shows that local version is 120, remote is 126, and status is "Old".

3) I run this command line to getlabel the file at "mylabel":

vault.exe -host 192.168.1.100 -user myusername -password mypassword -repository Core getlabel $/Foo/Bar.csproj mylabel -makewritable -setfiletime checkin -destpath c:\BUILD\ -merge overwrite

4) The local file is now the same bytes as is version 126 in repository. And the local file's datetime is the check in datetime for version 126.

But GUI shows local version is 120, remote is 126, and status is now "Needs merge". I am rather expecting it to show version 126 local and remote, with no status (i.e., up to date).

Thanks,
Brad

lbauer · Post by **lbauer** » Tue Feb 21, 2006 3:03 pm

Do you get the same results if you use -labelworkingfolder? The -destpath option assumes a get to a non-working folder and does not update state information. That could cause the unexpected results in the GUI Client.

bradw2k · Post by **bradw2k** » Tue Feb 21, 2006 3:10 pm

I see the same behavior if I use -labelworkingfolder rather than -destpath. Can you reproduce?

Brad

lbauer · Post by **lbauer** » Wed Feb 22, 2006 5:28 pm

I was able to reproduce the behavior when I used -destpath. But when I used -labelworking folder instead of -destpath, both the file and file list were appropriately updated. As I mentioned before -destpath assumes a get to a non-working folder, aund the Get does not update the client side cache files. -labelworkingdfafolder does update the cache.

I'm using Vault 3.1.7 client and server.

bradw2k · Post by **bradw2k** » Wed Feb 22, 2006 6:14 pm

What I try doesn't work, as described above. Please paste the command-line command that works for you. I wonder if some other option is a factor here.

Thanks,
Brad

lbauer · Post by **lbauer** » Thu Feb 23, 2006 12:38 pm

I pretty much copied your command:

vault -host server -user linda -password password -repository Repository GetLabel $/addfiles/FolderA/test.h mylabel -makewritable -setfiletime checkin -labelworkingfolder C:\_Vault\addfiles FolderA -merge overwrite.

I tried this again and reproduced your results, even using
-labelworking folder. But -- I realized I was logged into the Vault client as Linda and running the CLC as Admin. So the getlabel by Admin didn't update the client cache of Linda, causing the same problem that the
-destpath option did.

Could that be what you are seeing?

The other difference is I'm using 3.1.7, not 3.1.5.