4.1 VS 2005 problems

andrews · Post by **andrews** » Tue Mar 18, 2008 11:21 pm

Background:-

We checked in our codebase, including vs2005 projects etc.

We extracted them to a user's machine using Vault Client.

We then opened one of the projects in VS 2005, chose the Enhanced Client under Source Control options. We noticed that the project's Vault Bindings weren't set, so we opened the dialog and hit Bind.

Problems:-

It takes a lot longer to open a project with Vault active than it did previously. Now its 10 minutes of waiting for VS to finally let you do anything compared to 20 seconds before. Also VS seems to run a lot slower in general, with lots of temporary freezes. Sometimes the editing cursor disappears & doesn't return.

If you open a file and hit a key, it will automatically check it out (we use CVS mode). This means waiting about 10 seconds or more while the system goes off into deep space. Is there any way of stopping this auto checkout? Given that you could make a change accidentally on a file you just wanted to view, it'd be nice to force use of the "check out" option on the context menu.

The worst problem - having made a change, we can't checkin. The Pending Changes menu is empty, and if we right-click on a file in the Solution Explorer and hit Checkin, it tells us there's nothing to commit. We also can't undo checkouts as that option is greyed out. The files can be checked in using Vault Client instead, but this really isn't satisfactory.

Suggestions would be greatly appreciated.

ian_sg · Post by **ian_sg** » Wed Mar 19, 2008 8:13 am

I'm sorry you're having trouble. For obvious reasons, I'd expect things to get slightly slower when you add integrated source control to your IDE experience, but startup time jumping from 20 seconds to 10 minutes is certainly extreme. The frequent pauses and delays you're seeing also sound unusual.

The 10-second checkout might be a potential clue: what's the connection like between this workstation and the Vault server? On the same machine, iIf you check a file out using the stand-alone Vault client, how long does that take?

I'm not sure what might be causing the other problems you describe. Would you be willing to turn on diagnostic logging, re-open the solution, and reproduce the behavior you're describing? If you send me the resulting log, (attach it here or email it to ian at sourcegear dot com) I will take a look.

ian_sg · Post by **ian_sg** » Wed Mar 19, 2008 9:03 am

Jeremy just reminded me that we've recently fixed a long startup delay that affects all clients with certain repository layouts. Do you see a long delay when you start up the stand-alone Vault client?

andrews · Post by **andrews** » Wed Mar 19, 2008 3:42 pm

Hi Ian,

We're on a very fast network (sorry can't tell you the speed offhand) and Vault's on a new hi-spec win2008 server machine. We've tried this on two client machines, both 3.4ghz/1gb RAM.

Opening Vault Client we don't see much of a delay at all - its Visual Studio that has the problems. We tried it using the Classic plugin and it was just the same.

I'll turn on the diagnostics and get back to you

andrews · Post by **andrews** » Wed Mar 19, 2008 4:04 pm

I've attached the log. 99% of it is describing the startup process, with the bit at the end for when I try to commit a file.

Some more information from one of our testers. If we work in Edit->Merge mode _and_ we don't have a directory called <projectname>.ncb, then Vault allows checkins plus the Pending Changes works properly.

If we work in CVS mode or have that directory present then the checkin functionality is broken. (We have a directory called <projectname>.ncb in order to turn off Intellisense - we use Visual Assist instead).

Another problem with the Vault Client. We have one folder with a huge number of files (over 5000). If we open that folder in Vault Client it takes 12 seconds to display, which I guess is understandable if it has to retrieve the list from the server. The problem comes if we move focus to another window, then back to Vault Client again. It takes another 12 seconds to repaint the screen. If we open properties on a file in Vault Client, then close it ... another 12 seconds. You get the idea.

Unfortunately the above issues are sufficiently serious for us not to purchase Vault at this time. We're very pleased with pretty much everything else about Vault (it'd be nice not to have to write a plugin to capture events & fire off scripts on the Server though!) and your support on this forum is excellent, but these problems are showstoppers :\

ian_sg · Post by **ian_sg** » Thu Mar 20, 2008 9:10 am

We're still investigating, but I wanted to share some initial results.

While there's some room for improvement, the log doesn't show performance quite as bad as you described. Opening the solution took 62 seconds. That's not phenomenal, but the solution also has 78 projects. Less than a second per project seems respectable.

I then see a Get Latest, which took about 30 seconds. I didn't see a commit. What steps did you take to commit the change?

I also didn't see a checkout in this log, which would have been helpful to investigate the checkout delay you described.

andrews · Post by **andrews** » Mon Mar 24, 2008 5:27 pm

I'm not sure where you've getting the 62 second figure from. In the log file, I started opening project at 8.48.03am. Visual Studio remained in a busy state until 8.59.50am (line 17124 in the logfile). It may have taken 62 seconds to load all the subprojects, but what was it doing the rest of the time?

I then opened and edited a file. The first time I hit a keystroke to make a change, Visual Studio froze for 3 seconds or so while it automatically checked the file out. In the attached screenshot you can see the open file, the tick next to its name on the explorer, and the context menu showing Check Out is disabled. Strangely, Undo Check Out is also disabled. I don't know why this information isn't appearing in the logfile.

Back to the logfile - after making the change I saved the file and clicked Check In. From line 17125 onwards it records what happens during the Check In, which did nothing. The file did not appear in the Pending Changes list at all. In short, performance issues aside, my experience is that Vault is broken in Visual Studio if your repository's in CVS mode.

ian_sg · Post by **ian_sg** » Mon Mar 24, 2008 8:36 pm

Hmm. I'm not doubting your experience, but I am having trouble reconstructing it from the log.

Line 17124 at 8:59:50 shows the solution closing. The open, get latest, and checkin all happen before that, so it doesn't seem like Visual Studio could have been unresponsive that whole time. Even if you have the selected the option to automatically Get Latest when opening a solution, you would have seen a dialog with Get Latest options. I see a Get Latest starting at 8:53:12, line 11682.

However it does look like we spend an inordinate amount of time refreshing status information starting at 8:49:32 (line 9456). If the UI was non-responsive that whole time, that would be torturous. I'll play around with this when I'm back at work tomorrow morning.

It looks like you had 4 files checked out before you turned on the log, but no new checkouts were performed within the logged session. It might be helpful if you sent a log that did include a checkout.

If you grow tired of helping me investigate, let me also suggest that you try the Classic Client. It's more mature and works better for some solutions. (There's more information here.) I'm certainly not done trying to make the Enhanced Client work for you, but if the Classic Client meets your needs better in the short term I wanted to make sure that you are aware of it.