Codeplex 项目的 QueryHistory 无限期挂起

发布于 2024-09-05 14:43:02 字数 1146 浏览 7 评论 0原文

我正在开发一个 TFS 实用程序,用于获取 TFS 中特定项目的变更集。我有一个家用 TFS 2010 服务器,主要用于测试,但我决定在我参与的 Codeplex 项目中尝试一下。这样,我可以针对比本地数量更多的变更集来测试功能。

虽然它在我的环境中运行良好,但通过网络前往 Codeplex 让我感到困惑。我的应用程序查询历史记录,但是当尝试迭代历史记录时(即延迟加载 IEnumerable 时),我的应用程序挂起。

查看 Intellitrace,我看到一些“第一次机会”异常,即“指定版本中不存在该项目”——这显然是不正确的,因为我试图在 VersionSpec 中获取“$/”的历史记录。最新的。

我还看到在强制暂停调试后,向我返回了两个或三个连续的服务器 500 错误。

其他操作(如 GetItems() )工作正常,所以我很确定身份验证不是问题。

有什么想法吗?

这是代码:

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);
        }

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);
        }

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

ら栖息 2024-09-12 14:43:02

哎哟!找到了。问题出在我的 QueryHistory 调用上:

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);

我评论了上面的代码行。出于某种原因,我认为deletionId应该是“1”,但是,现在我查看了API,我意识到它应该是零(对于现有文件),或者文件的特定删除Id已被删除的。显然,API 正在寻找删除 ID 为“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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文