Dev Request (slow-performing right-click on large folders)

Nihimon · Post by **Nihimon** » Mon Feb 18, 2008 11:27 am

We have a project included in all of our Solutions that includes many thousands of files in a heirarchical folder structure. Right-clicking on this project can cause a 10-second delay before the context menu is displayed. This is only true when the project is using Vault as it's source control.

My belief is that the delay is caused by Vault checking all the files in the folder and all sub-folders in order to present a state-aware context menu of source control options on the standard context menu.

I would ask that the source control options be moved to a sub-menu named Source Control, and that the file checking only occur when that sub-menu is displayed.

Thanks,
Matt Knowles

ian_sg · Post by **ian_sg** » Mon Feb 18, 2008 11:34 am

Thanks for the feedback: we're aware of this issue. Is the project you mentioned a web site project? What version of Vault are you running?

Nihimon · Post by **Nihimon** » Mon Feb 18, 2008 11:53 am

The project is a library of all of our SQL script files that we use to create tables, views, stored procedures, etc. for our different projects. None of the content is compiled, but we want it under source control, for obvious reasons.

Nihimon · Post by **Nihimon** » Mon Feb 18, 2008 11:53 am

[2/18/2008 11:16:10 AM] Version Check: This Vault client is version 4.0.6.15954
[2/18/2008 11:16:10 AM] Version Check: Your Vault server is version 4.0.6.15954
[2/18/2008 11:16:10 AM] Version Check: The following information was retrieved from the SourceGear website. No information was sent to SourceGear. You can disable this part of the version check from the Options dialog.
[2/18/2008 11:16:10 AM] Version Check: The most recent Vault release is version 4.0.6.15954

ian_sg · Post by **ian_sg** » Mon Feb 18, 2008 11:55 am

Nihimon wrote:The project is a library of all of our SQL script files that we use to create tables, views, stored procedures, etc. for our different projects. None of the content is compiled, but we want it under source control, for obvious reasons.

I see. What project type did you use for this? Are they in a solution folder, or a database project, or something else?

Nihimon · Post by **Nihimon** » Mon Feb 18, 2008 12:02 pm

The project type is Class Library, but I don't think the project type is significant.

There is a folder named Scripts beneath the project folder, it has 2 sub-folders Projects and Schemas. These contain quite a few folders each and each of those contains a number of files, usually between 5 and 100 each.

Not that I think it's relevant, but just FYI:

The Projects folder contains a folder for each project we're working on, with a sub-folder for each deployed version. The version folder contains all the SQL script files that are specific to that particular release (table create scripts, specific data loading scripts, etc.)

The Schemas folder contains a folder for each database schema we have (usually one per project, but not always) and that folder has all the SQL scripts for permanent "source-code like" objects, such as views and stored procedures, which can be modified and re-run for subsequent version releases.

The end result, and the only thing I think is relevant, is that there is a large number of files in the heirarch. It seems apparent to me that Vault is doing something to check the status of each file in the heirarchy before displaying the context menu, and I believe this is due to putting the actual check-out/check-in commands directly on the main context menu and trying to make inappropriate menu items grey out.

ian_sg · Post by **ian_sg** » Mon Feb 18, 2008 12:11 pm

Thanks for the detailed response. Your deduction about the root cause is almost certainly correct.

Visual Studio's extensible project architecture is what makes the project type significant here. As a source control provider, we ask each project what files it has. Each project type implements this itself. For everything but web site projects, this is usually fast enough. It appears that you have a case where that's not true.

I've logged a bug to investigate this, and we may, at least in the short term, do exactly as you suggest and add a sub-menu.

I apologize for the inconvenience this is causing your team.

Nihimon · Post by **Nihimon** » Mon Feb 18, 2008 2:52 pm

Just FYI, I tried copying the top-level folder into each of a Console Application, Empty Project, Windows Application and Windows Control Library. All of these project types exhibit the same behavior: 10-second plus delays on right-clicking the project, or any folder beneath the project that has a large number of files below it, directly or heirarchically.

ian_sg · Post by **ian_sg** » Tue Feb 19, 2008 10:11 am

I neglected to mention that we made some significant improvements to the context menu command availability checks for 4.1.

You can try a beta version of the client today and it will talk to your 4.0.6 server. The final release of 4.1 will is due out very soon now, but it will require that you upgrade your server to 4.1 as well.

ian_sg · Post by **ian_sg** » Tue Feb 19, 2008 5:17 pm

One more update here: we did find and fix a another significant related significant bottleneck after beta 2 shipped. You'll see a significant difference in the speed of opening the context menu on projects with thousands of files between 4.1 beta 2 and 4.1 final.