GetByDisplayVersion API call doesn't use baseline file.

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

GetByDisplayVersion API call doesn't use baseline file.

Post by dking513 » Tue Sep 13, 2005 11:34 am

Hello,

I have a custom client that is using the vault API.

I have specified that baseline files should be stored in the working folders.
(I have done this programatically using ClientInstance.WorkingFolderOptions.StoreDataInWorkingFolders = True)

If I call the .Get method to get a file for the first time, the client downloads the file (and creates the baseline file in the hidden _sgvault folder). When I call .Get a second time for the same file, no file is downloaded, instead the baseline file is copied and renamed in the working folder. This is the correct behavior.

If I try to get prior versions of a file by using the .GetByDisplayVersion method, I am finding that it downloads the file every time - even though the first time seems to correctly create the baseline file.

I notice that if I use the VaultGUI client to get prior versions of the file, it appropriately uses the cached baselines. What am I doing wrong in my use of the API? What do I need to do programatically to make use of the caching?

Thank you,
Dave

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Sep 13, 2005 12:12 pm

Take a look at http://support.sourcegear.com/viewtopic.php?t=4172 for info on how to get a historical version without having to resort to getbydisplayversion. I'm assuming that you have run a history query which returns the objverid of the version you need to download.

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Post by dking513 » Tue Sep 13, 2005 12:25 pm

I'm a little confused by your reply. The thread that you sent me to suggests using GetByDisplayVersionToNonWorkingFolder.

Yes, I have a history query, so I have the ObjVerID.

Are you suggesting that I can set the objverid property of the file (as opposed to just the display version) and that this will correctly use the cache, even if I am calling one of the NonWorkingFolder methods?

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Sep 13, 2005 12:32 pm

The main thing I wanted you to see was getting the VaultClientFile object, cloning it, set the objverid, and then call the regular Get() method, which will hit the cache.

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Post by dking513 » Tue Sep 13, 2005 12:35 pm

Okay - I understand.
I have been getting the File object, cloning it, and setting the Version.
I'll set the ObjVerID instead and use .Get, and let you know how it works.
Thanks.

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Post by dking513 » Tue Sep 13, 2005 1:12 pm

In some cases, I don't have the ObjVerID handy.

Is there an efficient way to use the API to figure out the ObjVerID for a particular display version of a file if all I have is the File object and the desired display version number?

jeremy_sg
Posts: 1821
Joined: Thu Dec 18, 2003 11:39 am
Location: Sourcegear
Contact:

Post by jeremy_sg » Tue Sep 13, 2005 1:22 pm

In that case, I would recommend just using getbydisplayversion. There's no easy way for a client to get the objverid, so that's why we created getbydisplayversion. That's also why getbydisplayversion doesn't hit the cache, since the cache is keyed of objverid.

dking513
Posts: 48
Joined: Tue Apr 20, 2004 3:23 pm

Post by dking513 » Wed Sep 14, 2005 7:06 am

Jeremy,
Thanks for your help. I now have my client making use of the cache correctly. In the cases where I don't already have the objverid from a prior history query, I am performing a history query at that point to determine it. This doesn't take long, and the performance I pick up from the cache outweighs the time to lookup the objverid.
Thanks,
Dave

Locked