SourceGear Support

We have a customer who’s running 4.0.5, and the Vault API is reporting a large number of modified files when only 1 file is actually changed. The ProcessCommandListChangeSet calls returns ChangeSetItem objects with ChangeSetItemType 0 (Modified) for those files. Is this a cache problem? Any suggestions?

I would recommend that the customer compare the contents of the Vault GUI client's pending change window when logged in as that user on that machine and the output of the CLC's listchangeset command.

The customer figured this out:
--------------------------------------------------
I did however discover that if I changed the Vault IDE to 'Detect modified files from CRCs instead of modification times' that the detected files were correct. Turning that option off results in all the files being modified again. I tried deleting all my local files and doing a fresh get... changed the date/time stamps to be all the available options in Vault (check-in, modification, or current) and it made no difference.
--------------------------------------------------
Is there a way to override this setting in the API?

I'm using the Vault 4.0.6 client and am not seeing this behavior. Also, I assume my previously installed Vault 4.0.5 client also worked properly, as it would not have had this option checked either, and worked without returning all files modified.

It seems likely that something is touching the files' modification date after the get, which is why they are showing up modified using the simpler algorithm.

Here's my guesses:

1. Some other Vault user or Windows user is doing a second get to that location. This would explain why _everything_ gets its timestamp updated.
2. The API should be using the Vault user's setting for CRCs. Make sure that they are using the same Vault user with the CRC setting checked.

This issue is still occurring with the latest 4.1.2 client API we're using (from http://support.sourcegear.com/viewtopic ... 32&t=10824), i.e., ProcessCommandListChangeset returns all files modified (and in some cases returns no files modified), even when there are modified files.

This occurs on a customer's system who was the 4.1.2.18185 client installed, using CVS-style checkouts. The customer says there are no other users or other applications touching the files. As before, setting "Detect modified files using CRC's" fixes/works around this issue.

If it might be of any help, I've attached the logging from the Vault client api from the ProcessCommandListChangeset call.

Eric