| T O P I C R E V I E W |
| AndyFirth |
Posted - Jan 11 2012 : 12:08:52 PM
So we heavily use Visual Assist... we also heavily rely on branches however of late we've begun experiencing some oddness.
i have 6 branches, all the SAME code in various states for various teams, all synced at the same time and quite often 2-3 of them open in VS2010 at the same time.
the issue i hit is with either includes (add include) or with symbol to file resolution.... the worst i had gave me a choice for looking up a symbol.
Code:
<symbol_foo> -> <branchA>/blah/blah/blah/fileX
<branchB>/blah/blah/blah/fileX
<branchC>/blah/blah/blah/fileX
<branchD>/blah/blah/blah/fileX
<branchE>/blah/blah/blah/fileX
if i clear the Visual assist DB this resolves itself however thats not ideal.
if anyone has any insight we would definitely appreciate it. |
| 7 L A T E S T R E P L I E S (Newest First) |
| sean |
Posted - Jan 24 2012 : 9:49:07 PM
Andy, sorry that the ball was dropped yet again. I've responded to Steve. Let's keep discussion there so that it is in our support system. |
| feline |
Posted - Jan 17 2012 : 10:20:27 AM
Apologies for the slow reply. I have asked internally about this.
It partly depends on what VA is remembering. Most of the time, when producing listboxes and doing syntax colouring VA cares about the symbols, not the full path where the symbol came from. It looks like VA is remembering the symbols from all branches that it has seen.
If instead of branches of the same solution, you were opening code from a library that you are using then this behaviour could well make a lot more sense, and work well.
Clearly though, there is a problem here, and we need to try and find a reasonable solution. |
| AndyFirth |
Posted - Jan 12 2012 : 1:19:09 PM
i already setup (locally) to delete the files for myself automatically (we generate our solution/vcxproj anyway) however as a long term solution i didn't push this out to anyone else.
how is it "remembering" in this case... the path to all the files is different per branch so it seems that it should identify them differently in the database. |
| feline |
Posted - Jan 12 2012 : 12:48:04 PM
Clearly this is the wrong result, but I can see why it is happening, VA is remembering the solution from last time you opened it, and trying to be helpful, and trying to avoid rebuilding its entire symbol database each time you load a solution.
I was hoping that turning on parse all files when opening a project would help, but clearly this is not helping enough.
How long does a full symbol database rebuild take? I am wondering if launching the IDE from a script / batch file, that first manually deletes VA's symbol database would help? This is a crude and drastic solution, but it is fairly easy to implement, and will get things working now. |
| AndyFirth |
Posted - Jan 11 2012 : 4:25:43 PM
re: VA Options -> Performance -> Parse all files when opening a project
That option is on right now and i believe it is on my default.
I should note that this issue is affecting a large number of our developers, i just happen to be the person investigating. |
| feline |
Posted - Jan 11 2012 : 3:00:22 PM
Each IDE instance has its own symbol database, which are where the vs10_1, vs10_2, etc directories are coming from.
Do you have:
VA Options -> Performance -> Parse all files when opening a project
turned On or Off? If this is turned Off does turning it on help? |
| AndyFirth |
Posted - Jan 11 2012 : 12:36:05 PM
i "think" i've figured it out...
it seems the DB VA uses is per instance. The files it generates are named based on what looks like the Hash of the projectname, these project names are the same per branch.
when you open a project once it generates \\vs10_1\\ProjectInfo\\...
when you open a second branched instance it generates \\vs10_2\\ProjectInfo\\...
if you then CLOSE them all... and open the second branch it populates vs10_1 (started with BranchA) with information from BranchB.... the project filenames are the same so the resultant hash is the same ... what i'm seeing is a projectinfo file populated by information from both branchA & B.
this doesn't help me get it fixed... but it does seem to point to a cause. |
