Bug Report: MSSCCI-API - SccHistory return value

[PhilS]

Hi Sourcegear!

I observed another bug in the MSSCCI-API implementation in Vault 9.1.0 and would like to bring it up for discussion/evaluation.

When the function SccHistory is invoked in the Vault MSSCCI client library, it returns immediately after bringing up the History Explorer dialog. Unless there is a serious problem, it always returns SCC_OK. - This behavior is incorrect, as per specification of SccHistory.

If the "Get..." command from the context menu of History Explorer is used, SccHistory should return SCC_I_RELOADFILE to the caller instead of SCC_OK to enable the calling application to reload the now different file content. This is explicitly mentioned in the Remarks section of the specification.
Although not explicitly mentioned, the same should apply to the Rollback command in History Explorer.


So, as per specification this is a bug. Nevertheless, I'm slightly torn on whether I request to fix this.

Pro fix: For our Ivercy SCC plug-in for MsAccess the incorrect behavior is a problem. We need to know explicitly when a file must be reloaded in the immediate context of SccHistory.

Contra fix: Implementing the correct behavior as per spec, SccHistory would need to block the calling application and only return once the History Explorer dialog is closed. - I personally quite enjoy being able to open History Explorer and use it side-by-side with the IDE.


Question: Is it possible to make the Vault MSSCCI client to adhere to the spec by supplying a pvOptions argument to SccHistory? (I was too lazy yet to call SccGetCommandOptions to find out.)

Best regards,
Philipp

[Tonya]

Hi Phil,

We have logged this information and will check into implementing it into Vault 11.

Thanks again for all your input.

Tonya