Show Response Using Network Share

[webmonkdiverge]

I work from home and we are using a network share mapped to our development server in order to pull code to the dev environment. I am using Windows XP Pro and the server is Windows NT. We are using Fortress 1.1.3.

I know there will be added delay, checking out, in and other network functions will simply take longer. However, the delays I am seeing make the software unusable. The software is set with a working directory of the shared directory on the remote web server. Whenever I go to another window and come back to Fortress there is like a 5-30 second delay before the application will allow me to perform any actions. The time varies depending on the number of files in the directory the application currently displays. It is as if it is refreshing the data comparing the local and remote versions. But it really does not display updated version information. I have to hit F5 to get it to refresh that data, which compounds the delay.

My question is what is Fortress doing each time I place focus on the application? Is there any way to turn off whatever it is doing automatically and have it do it upon request so every time I have to jump back and forth to the application I am not being inundated with delays? Is there any known way to get Fortress to communicate more efficiently/faster over a broadband connection where the local working directory is a network shared directory?

Thanks!

[lbauer]

Is there any known way to get Fortress to communicate more efficiently/faster over a broadband connection where the local working directory is a network shared directory?

Fortress is optimized for the Internet by caching information on the client machine about baseline files (which help determing status of files in the working folder), checkouts, repository tree information, etc. In you case, the Vault Client connects to the remote server and also needs to communicate with the remote working folder, which slows things down.

You could try changing the locations for your cache and baseline files to see if that makes any difference. This is in Tools->Options->Local Files->Cache Location.

Is there a reason you need to use a remote working folder? -- after all, the latest files are stored in the repository and available to all Vault users.

[webmonkdiverge]

Thank you for your advice. I tried changing the settings as you mentioned without any change.

As far as the reason for having a remove local copy, it is simply the way that it was set up and communicated to me. The local copy is actually our development server. So when we check out files, change them and save them, we can immediately test on dev. When done we check them back in.

What I still do not understand is why just switching back to Fortress from another application causes it to recheck the local directory (or whatever it is doing). With directories with lots of files in them, it causes painful delay while I have to wait for it. A similar delay happens after I check in/out a file or perform any action on the file. Any additional advice would be appreciated.

[jeremy_sg]

The local check is to look for changes that might have been made in the other window (files that are now edited). It should only check the one directory that is currently selected. How many files do you have in that directory? Do you have ghost folders or ghost files turned on?

[webmonkdiverge]

It is noticeably slow with even a dozen files, but if it is an images directory with like 50 files, that takes forever. No, there are no ghost directories.

[jeremy_sg]

If you have CRCs enabled in Tools->Options->Local files, you should disable them.

[webmonkdiverge]

I do not have CRCs enabled. All advice so far has been good, but still have the problem.

Does anyone know when you leave the Fortress window to go do something else then come back to Fortress, what it is doing that causes it to be unusable until it is done? It does not seem to be refreshing the file information for the selected folder because it does not reflect updated files. That does not happen until I hit F5 (refresh). So not only do I have to wait when I return to the window, but I have to wait again after I hit F5, doubling the delay. If I cannot solve the delay it would be nice if, when returning to the window, it would not do what it does, but wait for me to hit F5. Or at least be able to hit "STOP" to cancel whatever it is doing.

Of course, the ideal is to solve the delay completely. Any more advice would be greatly appreciated.

[jeremy_sg]

Out of curiosity, does it behave as slowly if you set it to a network share that is not on NT?

A debug client log might help, as well.

[webmonkdiverge]

I misspoke in my original post. It is not NT, it is Windows 2000.

I will check into the debug client log.

[jeremy_sg]

Then I'll rephrase the question. Are things faster when you use a different server?