Way to clear the cache in the Client or through API?

montek · Post by **montek** » Fri May 04, 2007 9:09 am

I'm using version 3.1.9 (3798). If I use Visual Studio to retrieve a project from Vault, it works fine and all the files are retrieved. So, for example it retrieves the lastest version of all the files, say $/myproject/file.aspx 1, 2, 3, 4--it gets version 4 to disk.

What if I then want Vault to forget that it knows that version of THAT file is on disk? For instance, let's say I delete that file completely.

The client knows there's a problem, but the API still thinks it knows that version 4 was retrieved (which I can understand; the last thing that happened through Vault was that version 4 was retrieved).

Even if I reset the working folder to a different folder and then back, it seems the cache still knows that it retrieved version 4 to disk.

Is there any way to clear this? The only way I'm currently thinking this could work is to retrieve the files into a different folder. Delete all the files and change the working folder for the project and re-retrieve the files. But the problem might still be that it KNOWS about that version having previously been retrieved.

Any suggestions here?

In case you're wondering WHY I'm trying to do this: I have created a special application that uses the Vault API to retrieve the latest LABELED version of every file in the project. I have to first retrieve the entire project from Vault using Visual Studio to set up the project correctly, but then I'm trying to run this tool to retrieve the correct versions. This is working fine, except for the files that have never been labeled. They get fetched from the original get latest and even if I delete the files from disk, Vault still knows it retrieved them. I want it to forget so that our build tool, also written with the Vault API, knows that it should later re-retrieve that file when it's requested.

Sorry, I know it's long.

Beth · Post by **Beth** » Fri May 04, 2007 9:31 am

Is it that you don't want that file retrieved when you perform the Get by Label? If so, that file can be removed from the label using the Vault GUI and label promotion.

montek · Post by **montek** » Fri May 04, 2007 10:37 am

I'm not using the Get by Label function. I have custom built an application that retrieves the latest labeled versions of all files. It's not a specific label I'm after, it's just the latest labeled version.

I think I can get around this by retrieving the project to folderA and then deleting all that and running my tool on folderB, but I was hoping there was something within Vault that would allow me to tell it to forget the cache.

Beth · Post by **Beth** » Fri May 04, 2007 2:20 pm

The cache shouldn't come into play when you perform the get out to a different folder. Anything that goes to what is set as a working folder is logged in the cache.

montek · Post by **montek** » Fri Mar 14, 2008 8:53 am

Beth wrote:The cache shouldn't come into play when you perform the get out to a different folder. Anything that goes to what is set as a working folder is logged in the cache.

This does not actually work. Here's what I've done:

1. Retrieve an ASP.NET project through Visual Studio's get from source control to d:\temp.

2. Close Visual Studio and update IIS from d:\temp to d:\final.

3. Change the Vault working folder for the project from d:\temp to d:\final.

4. Use the API to fetch the latest labeled version of files.

Now, this works perfectly for files that actually have labels on them. Files that have yet to be labeled aren't requested at all. The problem is the Vault client shows the status as "Missing" but even though I've changed the actual working folder, the API still knows that it last retrieved version 6 of a specific file.

This is a problem because our custom build tool (built on the API) uses this "which version has been retrieved" to determine if it is supposed to update/overwrite later. For a file that has never been labeled, Vault seems to remember that--despite it having been done to a DIFFERENT working folder--version 6 was retrieved in the past, so the API thinks that's what's on disk.

What I want it to think--in the case of that file--is that there's NO VERSION that's ever been retrieved. I want the "Missing" status to reset the baseline version.

What I need to be able to do is destroy the cache completely--so the API and the Vault client NO LONGER KNOW which version was EVER retrieved of files. How can I do that?

lbauer · Post by **lbauer** » Fri Mar 14, 2008 3:08 pm

Working Folder State/Baseline file information is stored in the _sgvault folder.

I don't have a Vault 3.1.9 client handy, but I think that even back then, users had the option to store the _sgvault folder either in the same location as the client cache or in the working folder.

In your case, you may want to keep the baselines in the working folder so you can easily identify and delete the _sgvault folder(s) for those files.

This setting should be in the GUI Client under Tools->Options->Local Files.

montek · Post by **montek** » Mon Mar 17, 2008 6:50 am

I think the terminology is a bit confusing. We use the term "baseline" to mean the version last retrieved from Vault, not all the versions in the _sgvault folder.

The problem is that Vault seems to remember in its cache which version it last retrieved for you. I'm trying to figure out how to get it to FORGET that piece of information.

montek · Post by **montek** » Mon Mar 17, 2008 6:51 am

Oh, also, we'll be upgrading to version 4 here within the month but I don't know that this issue will change.

Post by **jeremy_sg** » Mon Mar 17, 2008 9:49 am

Monte,

Since you're obviously an advanced API user, I'll point you in the direction of WorkingFolder.DeleteFile(). That should do what you need it to.

montek · Post by **montek** » Mon Mar 17, 2008 11:02 am

Jeremy, this is fantastic! I haven't tried it but that sounds EXACTLY like what I need.

Beth · Post by **Beth** » Wed Mar 26, 2008 2:10 pm

.....

montek · Post by **montek** » Wed May 28, 2008 12:31 pm

I wanted to follow up on this issue. I'm tremendously pleased to report that it works exactly the way I need and has helped us create a tool that can reconstruct our latest build from Vault.

The only issue outstanding is that I *think* these methods are using the "old" style API, rather than the newer, documented and supported, one so I'll likely be forced to upgrade my codebase at some point.

Post by **jeremy_sg** » Thu May 29, 2008 7:49 am

You should only worry a little. Our new style API is built off of the old, so the old (VaultClientOperationsLib) api will stay around, and be much the way it is now. You may need to occasionally add a parameter here and there, but we're always going to be willing to answer your questions to get you running again.