API Force immediate changeset update after checking out file

[jkewley]

I'm writing a unit test for some code that I'm writing that uses the Vault Client API. The test checks out a single file, updates text in that file, then checks it back in. The problem is that the test runs very fast so the known changeset has not been updated locally, which means that Vault doesn't want to check the file in. I'm sure there's a way to refresh the changeset before iterating through, but I can't figure it out. Here is some of the code:

Code: Select all

public long CheckInFile(VaultClientFile aFile, string aCheckInComment) {
    ...
    //tried this
    theClientInstance.UpdateKnownChanges_File(aFile.Parent, theClientInstance.TreeCache.GetBestWorkingFolder(aFile.Parent), true);
    //and  this
    theClientInstance.UpdateKnownChanges_All(true);
    //and this
    theClientInstance.TreeCache.ChangeSetItems_Refresh(true);
    ChangeSetItemColl allPendingChanges = theClientInstance.InternalChangeSet_GetItems(true);
    foreach (ChangeSetItem aChange in allPendingChanges) {
        if(aChange.DisplayRepositoryPath == aFile.FullPath) {
            myChange = aChange;
            break;
        }
    }
    if(myChange == null) throw new VaultManagerException("You are trying to check in a file that hasn't been changed");
    ...
    theClientInstance.Commit(myLonelyChange, false, false, ref theNewID);
    return theNewID;
}    

How can I force the vault cache to realize that a local file checkout and edit has taken place before perusing the change set for my updated file?

Thanks
-Josh

[jclausius]

A couple of suggestions:

1) Can you verify the file is changed on disk (flush the file and close the file handle)?

2) Make sure the directory of the file which was changed has a valid working folder?

FWIW, the Vault client uses ClientInstance.UpdateKnownChanges_All(true), which goes through all assigned working folders, looking for changes to files.

[jkewley]

Jeff,

I got it to work using the Refresh method on ClientInstance. Out of curiosity, can you please explain the difference or offer any insight as to performance implications? It certainly runs faster than UpdateKnownChanges_All:

Code: Select all

public long CheckInFile(VaultClientFile aFile, string aCheckInComment) {
 ....
 theClientInstance.Refresh();
 ChangeSetItemColl allPendingChanges = theClientInstance.InternalChangeSet_GetItems(true);
 Console.WriteLine("Pending changes count:{0}", allPendingChanges.Count);
 foreach(ChangeSetItem aChange in allPendingChanges) {
     if(aChange.DisplayRepositoryPath == aFile.FullPath) {
         myChange = aChange;
         break;
     }
 }
 if(myChange == null) throw new VaultManagerException("You are trying to check in a file that hasn't been changed");
 ......
}

-Josh

[jclausius]

I just went through some of our own Unit Tests, and discovered some interesting info.

After a change is made to the file the NUnit test then does a Thread.Sleep(1) or Thread.Sleep(2001) depending on the file system (NTFS vs. FAT-32), and then it saves the file.

What may be happening in your case is what we've seen. The Edit/Save takes place so fast, the Client API does not see a change in the timestamp of the file. Introducing a small delay in the test solved the problem.

Also note, using CRC for detection changes is another way around the time stamp problem.

If you do introduce a delay or switch to CRC checking, then your original code w/ UpdateKnownChanges_File() is the most efficient way to test things.

HTH

[jkewley]

Interesting, because I just looked through the NAnt task VaultCheckIn, and you guys are using the ClientInstance.Refresh() method there. This must force a Tree refresh, but it appears to execute much faster than ChangeSetItems_Refresh.

Do you guys have a plan for when you might do more work on documenting and solidifying the API?

[jclausius]

The ClientInstance.Refresh is a heavy operation since it updates the local TreeCache with any changes on the server. In a NAnt task, we want to make sure the tree is up to date with all info before anything is executed.

In a NUnit test, that is usally not required because you're in a more controlled environment.

As for the documentation, I'm sorry to report there's nothing new to report at this time.

[jkewley]

Ok, I know I'm asking a whole heck of a lot here, but this should be fairly easy (and safe) to do with a product like ReSharper. For those methods that take path parameters as strings, it'd be nice if they were named something that was self documenting. For example:

Code: Select all

TreeCache.GetWorkingFolder(string fullPath)

would be a heck of a lot easier to work with if it were

Code: Select all

TreeCache.GetWorkingFolder(string fullRepositoryPath)

to help indicate that you are looking for $/root/path/file.txt instead of F:\working\path\file.txt. After working with your APIs for a bit, I'm comfortable with determining which path you're looking for, but I think using more verbose parameter names will help other people who want to start using it as well.

Total long shot, but I figured I'd throw it out there.

Another nice shortcut would be to have a property available on a VaultClientFile and VaultClientFolder that returns the working path. (preferably the inherited path, such as is available from GetBestWorkingFolder on the TreeCache)

[jclausius]

Thanks for the suggestions.