ankhsvn
Issue 618

In AnkhSVN 2.1.7867.426 on VS 2010 RC1, opening a project
hangs with many thousands of  these entries in the stack:

Ankh.Services.dll!Ankh.SvnItem.IsIgnored.get() Line 1172 + 0x24 bytes   C#.

As you can see from the stack trace, it ends with a status check of a
networked path file (not even in the solution, although probably
referenced from one of the PDBs or somewhere else, or was opened by
Visual Studio and is still resides in the recently opened files).

------- Additional comments from Yuri A Wed Mar 3 09:12:18 -0700 2010 -------

Created an attachment (id=50)
Breakpoint screen shot #1

------- Additional comments from Yuri A Wed Mar 3 09:12:30 -0700 2010 -------

Created an attachment (id=51)
Breakpoint screen shot #2

------- Additional comments from Sander Rijken Wed Mar 3 16:19:10 -0700 2010 -------

Can you reproduce this? If so can you show the other side of the stack trace, or copy/past the complete 
stack trace in the issue? I'm wondering what it is that starts calling IsIgnored.

------- Additional comments from Yuri A Wed Mar 3 18:18:47 -0700 2010 -------

The callstack is too long - it does not show the bottom. It happens every time i
tried to open a specific solution. Other solutions open fine. Will see if I can
find the originator of that ignore call.

------- Additional comments from Sander Rijken Thu Mar 4 03:05:03 -0700 2010 -------

The issue here seems to be that in the case of UNC paths we don't detect that we are at the root because 
of a bug in the code used to determine the parent of an SvnItem. The code containing the bug is in the 
SharpSvn library we use. It shouldn't take long to get that fixed.

When that's fixed, I'm still interested to find out why we scan the UNC path in the first place. It'll probably 
be much easier for you to figure that out when the callstack is more managable/complete.

------- Additional comments from Bert Huijben Thu Mar 4 05:49:30 -0700 2010 -------

The SharpSvn issues are fixed in SharpSvn 1.6009.1480, which will be
included in our next daily build.

------- Additional comments from Yuri A Thu Mar 4 09:27:05 -0700 2010 -------

Installing AnkhSVN 2.1.7872 fixed the locking up issue (project opened fine).

I could still try to investigate why the UNC file is being accessed, but not
sure how to go about doing it -- where should i set the breakpoint?

Do you distribute PDBs with the daily builds?

------- Additional comments from Sander Rijken Thu Mar 4 09:51:44 -0700 2010 -------

It would be very good to know why Ankh looks at the network in this case. The endless loop has been 
solved now, but checking Subversion statuses on the network when it's not necessary will cause us to spend 
more time during startup/load than required.

The easiest way to debug why it looks at the network at this point is to run a debug build yourself. The only 
dependency required to build AnkhSvn is the Visual Studio SDK (the 2010 beta2 SDK in your case).

After installing that, set Ankh.Package as startup project, right-click the project and go to Properties -> 
Debug.
- Set Start Action to the path to devenv.exe (C:\Program Files\Microsoft Visual Studio 
10.0\Common7\IDE\devenv.exe)
- Set the arguments to /rootSuffix Exp /RANU

I would recommend setting a breakpoint at the Ankh.Scc.StatusCache.FileStatusCache indexer. All requests 
for SvnItems (the class representing an on-disk file/directory) go through this point. Set it to only break if 
the path starts with the UNC path.

Thanks

------- Additional comments from Yuri A Thu Mar 4 10:34:38 -0700 2010 -------

Sander, I will try to setup the build environment, but it would have been much
easier if all I had to do was place the PDB files in ankhsvn dir and targeted VS
to the source code. Can the daily build script be configured to include them?
Daily builds are already for dev community, might as well publish a few more MBs
to simplify things. As an example - Resharper team alread does that with all
their nightly builds.

Thx!

------- Additional comments from Yuri A Thu Mar 4 11:32:06 -0700 2010 -------

It turns out the csproj actually did include a reference to that file in one of
the item groups:

    <Content Include="\\config\c%24\Config\BusinessData\SomeFile.xml">
      <Link>OurData\SomeFile.xml</Link>
    </Content>

It was done by a developer for quick access to the file during debugging,
without actually using that file for the build.

As a result, the indexer on FileStatusCache was called with:

\\config\c$\Config\BusinessData\SomeFile.xml
\\config\c$\Config\BusinessData
\\config\c$\Config
\\config\c$

------- Additional comments from Sander Rijken Thu Mar 4 14:56:24 -0700 2010 -------

Fixed in daily builds, no need to hunt why we might hit the network for the wrong reason

------- Additional comments from Bert Huijben Fri Mar 5 03:19:36 -0700 2010 -------

Starting with the last daily build we will upload symbols of the daily build:

See the Documents & Files section or look at:
http://ankhsvn.open.collab.net/servlets/ProjectDocumentList?folderID=348

Quick note:
All our PDB's are sourceserver enabled. If you enable Source Server Support in
Tools->Options->Debugging you can automatically retrieve the sourcecode via 
svn.exe.

Just make sure that you browsed to
http://ankhsvn.open.collab.net/svn/ankhsvn and
http://sharpsvn.open.collab.net/svn/sharpsvn 
before you try to retrieve source files, or svn.exe will fail to ask for a 
password.

------- Additional comments from Sander Rijken Fri Mar 5 03:34:50 -0700 2010 -------

*** Issue 617 has been marked as a duplicate of this issue. ***