QueryHistory against a codeplex project hangs indefinitely

Question

I'm working on a TFS utility that gets the changesets for a particular project in TFS. I've got a home TFS 2010 server which I primarily use for testing, but I decided to give it a try against a codeplex project to which I contribute. That way, I can test functionality against a larger number of changesets than I have locally.

While it works fine in my environment, heading out over the wire to codeplex has left me stumped. My application queries the history, but then, when trying to iterate through the history (which is when it lazy-loads the IEnumerable), my application hangs.

Looking at Intellitrace, I see a couple of "first chance" exceptions that the "item doesn't exist at the specified version"-- which is patently not true, as I'm trying to get history for "$/" at VersionSpec.Latest.

I also see two or three consecutive server 500 errors being returned to me after forcing debugging to pause.

Other operations (like GetItems() ) work fine, so I'm pretty sure authentication isn't an issue.

Any thoughts?

Here's the code:

IEnumerable items = vcs.QueryHistory("$/", VersionSpec.Latest, 1, RecursionType.None, null, null, null, 5, true, false);

        List<ChangesetItem> returnList = new List<ChangesetItem>();
        foreach (Changeset cs in items)  //hangs here on first iteraiton
        {
            ChangesetItem newItem = new ChangesetItem()
            {
                ChangesetId = cs.ChangesetId,
                //ChangesetNote = cs.CheckinNote.Values[0].Value,
                Comment = cs.Comment,
                Committer = cs.Committer,
                CreationDate = cs.CreationDate
            };

            returnList.Add(newItem);
        }

Answer 1

Doh! Found it. The problem was on my QueryHistory call:

IEnumerable items = vcs.QueryHistory("$/", 
                  VersionSpec.Latest, 
                  1, // the deletionId should be '0' or a unique deletion identifier
                  RecursionType.None, 
                  null, 
                  null, 
                  null, 
                  5, 
                  true, 
                  false);

I commented the line of code above. For some reason, I thought deletionId was supposed to be '1', however, now that I've looked at the API, I realize that it is supposed to be a zero (for existing files), or the specific deletion Id for files that have been deleted. Apparently, the API was looking for a file with deletionId of '1', which it couldn't find, thus causing the crash.