Equivalent to Vault Tools/Options in API?

[robe070]

Hi,
I'd like to know how to control the equivalent of the settings in Tools/Options of the Vault Client and in particular
Tools/Options/Network Settings from the API.

The code is the Vault Plugin Template, slightly modified.

We use ServerOperations.Login(); to login but I can't see the equivalent options in ServerOperations.client.LoginOptions.

[Beth]

The API doesn't have a way to change those settings.

The client settings are in the registry under HKEY_CURRENT_USER\Software\SourceGear\Vault\Client\Settings or HKEY_CURRENT_USER\Software\SourceGear\VaultPro\Client\Settings depending on which you are using. You can place the registry settings into a .reg file and then import them using regedit /s filename.

[robe070]

So how do I determine the current-user when this is a Vault Plugin executing on the server via IIS? I'm a little ignorant when it comes to IIS.

[Beth]

I'll need to do some looking to find where that information will be and will post back.

[robe070]

Another tack - I've posted this thread in relation to our other discussion on Vault performance http://support.sourcegear.com/viewtopic.php?f=5&t=15457

That is, would any of the Network Settings that you've suggested might make a difference for the Vault Client, make a difference to this Vault Plugin?

thanks for your help

[Beth]

So how do I determine the current-user when this is a Vault Plugin executing on the server via IIS? I'm a little ignorant when it comes to IIS.

You will have the task running under some Windows user login, and that user's settings will be what you want to look at.

That is, would any of the Network Settings that you've suggested might make a difference for the Vault Client, make a difference to this Vault Plugin?

Yes. I think most of those should also be in the registry under the Vault client settings.

[robe070]

thanks

So the settings are present in the registry. But will they all make a difference in this situation?

Use expect 100...? Seems it should be checked on the same box?

Repository cache delta...? The plugin doesn't execute a repository cache delta does is? (unless you request it)

[Beth]

The Vault Client API should work just like a client would, so the settings should have the same affect on the API as it does the Vault GUI client.

Use expect 100...? Seems it should be checked on the same box?

I am not sure what you mean about it being on the same box. Are you saying you checked it on a client on the same machine?

Repository cache delta...? The plugin doesn't execute a repository cache delta does is? (unless you request it)

This affects the tree shown in Vault, not the files sitting on your disk. Turning this off has been shown to make Vault start-up faster.

It would be better to keep performance questions in the performance thread if we can rather than dividing it between two threads in two different parts of the forum.

[robe070]

The Vault Client API should work just like a client would, so the settings should have the same affect on the API as it does the Vault GUI client.

Use expect 100...? Seems it should be checked on the same box?

I am not sure what you mean about it being on the same box. Are you saying you checked it on a client on the same machine?

Repository cache delta...? The plugin doesn't execute a repository cache delta does is? (unless you request it)

This affects the tree shown in Vault, not the files sitting on your disk. Turning this off has been shown to make Vault start-up faster.

It would be better to keep performance questions in the performance thread if we can rather than dividing it between two threads in two different parts of the forum.

This thread is about what effects the Vault Plugin performance. I would like to keep it separate becasue I think the answers may be different. Its not the Vault Client. Its is a kind of Client, but it will only use a subset of Vault features. The features used will be what I have put in the program. Given that its essentially exactly the same as provided by SourceGear, you know what features of the API are used and therefore whether the settings highlighted above will effect it or not.

Your comments above seem to all be about the Vault Client shipped by SourceGear, and not about the Plugin and the parts of the api it uses. e.g. "This affects the tree shown in Vault". The Plugin isn't showing anything!

The special thing about the Plugin is that it is executing on the same machine as the Vault Server. Thats not special to our use. I would have thought that anyone using the Plugin would be using it the same way. Hence my question about the latency setting.

I would expect that specific parts of the API will be effected by particular settings. I'm trying to work out which ones.

[Beth]

Sorry for mixing in the part on the GUI client. I was trying to convey that a delta is requested for more than just a Get Latest or updating files in your working folder. The repository cache delta is retrieved whenever there is a refresh. Unless you know exact paths and IDs, working with the repository within ServerOperations.ClientInstance will most likely force you to call .Refresh(). Doing so will require the server to update your client repository through a repository delta.

When the plugin is on the same machine as the Vault server, do you connect using localhost? If not, then there's a chance the communication goes out of the server and returns.

[robe070]

We do not call .refresh as we are after the transaction information so we can record it in our bug tracking system. Apart from logging on, these are the only apis we use:

Code: Select all

ServerOperations.client.ClientInstance.TreeCache.Repository.Root.FindFolderRecursive(pathToWatch);
ServerOperations.client.ClientInstance.TreeCache.Repository.Root.FindFileRecursive(pathToWatch);
ServerOperations.client.ClientInstance.ListRepositories(ref reps);
ServerOperations.ProcessCommandTxDetail(txID);

So therefore I think the cache setting is irrelevant. We are also not getting any spgetrepositorydelta calls on the server when the plugin runs.

Latency setting may have an effect, but I'd hope that the network layer was sensible enough to understand the IP address is localhost. I'll keep it in mind.

I think we need to restructure the Plugin so it only logs in once, rather than every time a check in occurs.

[Beth]

Do you have any performance issue in the API that is not also happening in the GUI client?

[robe070]

Hi Beth,

I have executed rapid check ins to exercise the Plug In and it coped with 27 check ins in 11 seconds. Note that this was not using the Vault Client. With the 8 second delay it can't get within cooee of this rate of transactions. So the Plugin is now

I achieved this by synchronising access to the Plugin by using a critical section. This stopped the errors occurring when the refresh occurred. (The stack trace when the error occurred showed that one of the apis used by the Plugin causes a .refresh internally.) I would recommend that any user of the Plugin puts a critical section around everything except the login. I left the login out as it still wotks (!) and also allows the login to take place whilst waiting for the resource to come free - multiple threads get started by Vault.

I have not changed the login - it still logs in for every transaction. But as we can see by the txn rate above, it hardly matters. I also noticed that most of the time is taken by the refresh, not the login. And the refresh must occur.

We have not noticed any login/refresh type delays with the Plugin at any stage. This thread was started in order to see if the Vault Client settings mentioned previously might effect the Plugin. We have ended up not confirming whether they do or not.

Its running fast so onto the next issue!

[Beth]

Thanks for the update. Other users may find this helpful.