请问TFS2010的文档、代码的版本控制功能用的是Sharepoint吗？TFS的版本控制功能与SVN对比有哪些优缺点？
如果版本管理用SVN，其他功能用TFS，这么结合用油什么利弊，谢谢各位了！
TFS的文档和portal部分用的是SharePoint，Version Control 是TFS自带的。在我看来，如果你已经有TFS了你就没有必要再安装一个SVN了。 TFS的Source Control的功能不比SVN差而且更佳，它提供了比SVN更强大的功能，比如 Shelve, 和work item 的集成，可以查看Merge的历史记录等等，这些都是SVN中没有的。我想你有一个TFS就已经足够了，为什么要将它和SVN结合起来一起使用呢？&Vicky Song [MSFT]
MSDN Community Support |
已标记为答案
TFS的文档和portal部分用的是SharePoint，Version Control 是TFS自带的。在我看来，如果你已经有TFS了你就没有必要再安装一个SVN了。 TFS的Source Control的功能不比SVN差而且更佳，它提供了比SVN更强大的功能，比如 Shelve, 和work item 的集成，可以查看Merge的历史记录等等，这些都是SVN中没有的。我想你有一个TFS就已经足够了，为什么要将它和SVN结合起来一起使用呢？&Vicky Song [MSFT]
MSDN Community Support |
已标记为答案
TFS的文档和portal部分用的是SharePoint，Version Control 是TFS自带的。在我看来，如果你已经有TFS了你就没有必要再安装一个SVN了。 TFS的Source Control的功能不比SVN差而且更佳，它提供了比SVN更强大的功能，比如 Shelve, 和work item 的集成，可以查看Merge的历史记录等等，这些都是SVN中没有的。我想你有一个TFS就已经足够了，为什么要将它和SVN结合起来一起使用呢？&
Vicky Song [MSFT]
MSDN Community Support |
多谢啊，不太了解TFS的强大功能，我以为SVN在版本管理方面功能更强大呢。另外请教一下Vicky，代码和文档的Version Control 都是用的TFS自带的。
Microsoft 正在进行一项网上调查，以了解您对 Msdn 网站的意见。如果您选择参加，我们将会在您离开 Msdn 网站时向您显示该网上调查。是否要参加？
<input type="hidden" id="hdnTrackerText" value="请不要关闭此窗口。谢谢！完成访问时，调查将显示在此处，所以请不要关闭此窗口。" />TFS源代码管理设置的问题_百度知道
此问题是因为你没有项目团队管理员权限，只有项目管理员才会拥有源代码管理权限对源代郸工策继匕荒察维畅哩码的签出策略签出策略进行设置
其他类似问题
源代码的相关知识
您可能关注的推广回答者：
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁TFS 使用心得--权限管理 - fqz_fighting的个人空间 - 51Testing软件测试网 51Testing软件测试网-中国软件测试人的精神家园 - Powered by X-Space
Seeing is not believing,testing is believing.
TFS 使用心得--权限管理
& 18:06:24
/ 个人分类：
&&& 最近一段时间负责管理公司技术人员的TFS的权限分配，在此之前，我对tfs一点都不了解，没用过，也没听朋友用过，只在进公司时指导我的组长帮我把这个工具装上，告知要在上面报bug，即bug管理在上面，之后的很长一段时间就只知道tfs可以管理bug，可以管理文档，可以管理源代码，这点是从我负责的那个项目下的文件夹中看到的，至于怎么来管理，其中有多复杂，没有太多的了解。&&&&指导两个月前，接手tfs权限管理以来，才知道里面有多复杂，经理只告诉我怎么分配项目成员的项目权限，的都不知道，起初还以为这样就万事大吉了，呵呵，原来那些只是皮毛，里面的权限还十分的复杂，这是在我两个月来的管理中琢磨出来的，凭现在对tfs权限管理的了解，基本可以应对公司员工的tfs权限的分配。&&& 说tfs权限的复杂，其实也不是很复杂，它只是把各部分的权限分开控制，但各部分的权限又可以相互继承，分的多了，操作起来就容易出现问题，关联的多了，更容易出现问题，继而形成了它的复杂度。&&&&下面来分享一下我的使用心得，我还是刚入手，了解的一点点，拿来汇总一下，以便今后的工作和，有帮助的可以看看。&&&&tfs的权限分不同的级别，不同级别的权限其安全性不同，这点帮助文档中部分信息十分完备：&&&& 权限决定了是否授权用户进行工作区管理和项目创建等操作。当在 Team Foundation Server 中创建项目时，无论选择哪种过程模板，都会为该项目创建四个默认组。默认情况下，为这些组各自定义了一组权限，这些权限决定了组成员可以执行的操作。Project AdministratorContributorReaderBuild Services要管理默认组并创建自定义组，管理员必须了解权限的含义以及显式设置权限引起的安全问题。注意：本主题不讨论
SharePoint Services 或
Reporting Services 的权限。本主题只讨论在 Team Foundation Server 中设置的权限。Team Foundation Server 中的权限有两种显式授权设置：“拒绝”和“允许”。还有一种隐式授权，它既不将权限设置为“允许”，也不将其设置为“拒绝”。此授权是一种隐式“拒绝”设置，又称为“未设置”。“拒绝”不允许授权用户或组执行权限说明中提到的操作。“拒绝”是 Team Foundation Server 中最强大的权限设置。如果用户所属的 Team Foundation Server 组将特定权限设置为“拒绝”，那么即使用户所属的另一个组将该权限设置为“允许”，该用户仍无法执行该功能。此规则的唯一例外是用户属于项目的“Project Administrators”组的成员或者属于“Team Foundation Administrators”组的成员的情况。如果用户是项目的 Project Administrators 同样，如果用户是 Team Foundation“Administrators”组的成员，则该组的特权将覆盖该用户在 Team Foundation Server 中的显式“拒绝”。“允许”则允许授权用户或组执行权限说明中提到的操作。“允许”是 Team Foundation Server 中第二强大的权限设置。它也是设置最频繁的权限设置。如果不将权限显式设置为“允许”，用户或组将不能在 Team Foundation Server 中执行该操作。默认情况下，Team Foundation Server 中的多数权限既没有设置为“拒绝”，也没有设置为“允许”。权限处于“未设置”状态，它隐式拒绝授权用户和组执行权限说明中指定的操作。但是，因为权限既没有显式设置为“拒绝”，也没有显式设置为“允许”，它可以从用户或组所属的其他组继承授权。当用户或组的权限为“未设置”时，因为 Team Foundation Server 中的权限是可继承的，所以用户或组可能受到其所属组权限的显式设置的影响。例如，如果一个用户属于某一项目中的两个自定义组，其中一个组将权限显式设置为“拒绝”，另一个组将同一权限保留为“未设置”，用户将无权执行该权限所控制的操作（用户从两个组中都继承了权限，“拒绝”优先于“未设置”权限）。注意：在 Team Foundation Server 以外（如 Windows SharePoint Services 中）设置的权限，不会在 Team Foundation Server 中继承。本主题中不对其进行讨论。某些授权设置优先于其他授权设置。在 Team Foundation Server 中，“拒绝”权限优先于包括“允许”在内的所有其他权限设置。例如，用户可能属于一个项目中的两个组。对于其中一个组，“发布测试结果”权限设置为“拒绝”；而另一个组则将该权限设置为“允许”。“拒绝”设置优先级更高，用户无权发布测试结果。此规则的唯一例外是用户属于项目的“Project Administrators”组的成员或者属于“Team Foundation Administrators”组的成员的情况。如果用户是项目的 Project Administrators 同样，如果用户是“Team Foundation Administrators”组的成员，则该组的特权将覆盖该用户在 Team Foundation Server 中的显式“拒绝”。许多要为 Team Foundation Server 设置的权限是通过 Team Foundation Server 用户界面控制的。您可以根据服务器（服务器级别权限）或项目（项目级别权限）设置这些权限。您还可以根据项目为查看工作项以及与工作项交互设置区域级别权限。有关默认情况下为哪些用户设置哪些权限，以及为 MSF for Agile Software Development 或 MSF
Process Improvement 组设置哪些权限的更多信息，请参见。有关如何为用户和组设置权限的更多信息，请参见和。有关管理工作项的更多信息，请参见管理 Team Foundation 工作项。服务器级别权限不特定于单个项目，而是在服务器范围设置的。只能为三个类别的用户设置这些权限：服务器级的用户和组，如 Team Foundation Administrators已在 Team Foundation 服务器上添加至服务器级的项目级组您创建并添加至服务器级的自定义组您可以通过在 Team Foundation Server 中右击团队资源管理器中的服务器，然后单击“安全”来设置这些权限。您可以使用TFSSecurity命令行实用工具来设置这些权限，带有tf:标识的命令行实用工具除外。对于带有tf:标识的权限，可使用源代码管理的tf命令行实用工具的Permission命令设置这些权限。有关更多信息，请参见和Permission 命令。权限名称命令行中的名称说明管理搁置的更改tf: AdminShelvesets具有该权限的用户可以删除其他用户创建的搁置集。管理仓库ADMINISTER_WAREHOUSE具有该权限的用户可以使用 WarehouseController.asmx Web 服务的 ChangeSetting Web 方法更改仓库设置。例如，您可以允许用户设置计算 OLAP 多维数据集的更新时间间隔。管理工作区tf: AdminWorkspaces具有该权限的用户可以为其他用户创建工作区并删除其他用户创建的工作区。创建工作区tf: CreateWorkspace具有该权限的用户可以创建源代码管理工作区。创建新项目CREATE_PROJECTS具有此权限的用户可以在 Team Foundation Server 中创建新项目。为了成功创建新项目，这些用户必须是 Windows SharePoint Server 中“SharePoint Central Admins”组的成员，并且在 SQL Reporting Services 中具有“内容管理员”权限。编辑服务器级的信息GENERIC_WRITEtf: AdminConfigurationtf: AdminConnections具有此权限的用户可以编辑 Team Foundation Server 上用户和组的服务器级别权限。他们可以从 Team Foundation Server 中添加或移除服务器级的 Team Foundation Server 应用程序组。当通过菜单设置时，“编辑服务器级别信息”权限还将隐式允许用户修改源代码管理权限。若要从命令行授予上述所有权限，必须使用tf.exe Permission命令授予AdminConfiguration和AdminConnections权限，以及 GENERIC_WRITE。注意：无法删除 Team Foundation Administrators 等默认服务器组。改变跟踪设置DIAGNOSTIC_TRACE具有此权限的用户可以更改跟踪设置，以收集有关 Team Foundation Server Web 服务的更详细的诊断信息。有关跟踪的更多信息，请参见。触发事件TRIGGER_EVENT具有此权限的用户可以在 Team Foundation Server 中触发项目警报事件。该权限只应指派给服务帐户。管理过程模板MANAGE_TEMPLATE具有此权限的用户可以从 Team Foundation Server 下载、向其上载、创建和编辑过程模板。查看服务器级别信息GENERIC_READ具有该权限的用户可以查看服务器级别的组成员资格以及那些用户的权限。查看系统同步信息SYNCHRONIZE_READ有此权限的用户可触发同步事件。该权限只应指派给服务帐户。项目级别权限特定于单个项目的用户和组。您可以通过在 Team Foundation Server 中右击团队资源管理器中的项目，单击“团队项目设置”再单击“安全”来设置这些权限。还可以使用“TFSSecurity”命令行实用工具来设置这些权限。权限名称命令行中的名称说明删除此项目DELETE具有此权限的用户可以从 Team Foundation Server 中删除他们有权删除的项目。编辑项目级信息GENERIC_WRITE具有此权限的用户可以编辑 Team Foundation Server 上用户和组的项目级别权限。发布测试结果PUBLISH_TEST_RESULTS具有该权限的用户可以添加或移除团队项目门户的测试结果，也可以添加或移除测试运行。查看项目级信息GENERIC_READ具有该权限的用户可以查看项目级别的组成员资格以及那些项目用户的权限。生成级别的权限特定于生成计算机的用户和组。您可以通过右击团队资源管理器中的项目，单击“团队项目设置”再单击“安全”来设置这些权限。另外，您还可以使用TFSSecurity命令行实用工具设置这些权限。权限名称命令行中的名称说明管理版本ADMINISTER_BUILD具有该权限的用户可以删除完成的生成并停止正在进行的生成。编辑版本质量EDIT_BUILD_STATUS具有此权限的用户可以通过 Team Foundation Build 用户界面添加有关版本质量的信息。此信息存储在 Team Foundation Build 的存储区中。启动版本START_BUILD具有此权限的用户可以通过 Team Foundation Build 界面或从命令行启动版本。写入版本操作存储区UPDATE_BUILD必须向用于运行生成服务的帐户授予此权限，才能更新 Team Foundation Build 的数据库存储区。此权限应只分配给服务帐户，而不应分配给单个用户。区域级别权限特定于单个项目的用户和组。您可以通过右击团队资源管理器中的项目，单击“区域和迭代”，在“区域”选项卡上单击“安全”来设置这些权限。另外，您还可以使用TFSSecurity命令行实用工具设置这些权限。注意：某些工作项跟踪操作需要多种权限。例如，您需要多种权限来删除节点。权限名称命令行中的名称说明创建子节点并对子节点排序CREATE_CHILDREN有此权限的用户可以创建新的区域节点。同时具有此权限以及“编辑此节点”权限的用户可以移动任何子区域节点或对任何子区域节点重新排序。删除此节点DELETE同时具有此权限以及对另一个节点的“编辑此节点”权限的用户可以删除区域节点并对所删节点中的现有工作项重新分类。删除的父节点下的任何子节点将同时删除。编辑此节点GENERIC_WRITE具有该权限的用户可以重命名区域节点。编辑此节点中的工作项WORK_ITEM_WRITE具有该权限的用户可以编辑此区域节点中的工作项。查看此节点GENERIC_READ具有该权限的用户可以查看此节点的安全设置。查看此节点中的工作项WORK_ITEM_READ具有该权限的用户可以查看，但不能编辑或更改此区域节点中的工作项。迭代级别权限特定于单个项目的用户和组。您可以通过右击团队资源管理器中的项目，单击“区域和迭代”，在“迭代”选项卡上单击“安全”来设置这些权限。另外，您还可以使用TFSSecurity命令行实用工具设置这些权限。注意：某些工作项跟踪操作需要多种权限。例如，您需要多种权限来删除节点。权限名称命令行中的名称说明创建子节点并对子节点排序CREATE_CHILDREN具有此权限的用户可以创建新的迭代节点。同时具有此权限以及“编辑此节点”权限的用户可以移动任何子迭代节点或对任何子迭代节点重新排序。删除此节点DELETE同时具有此权限以及对另一个节点的“编辑此节点”权限的用户可以删除迭代节点并对所删节点中的现有工作项重新分类。删除的父节点下的任何子节点将同时删除。编辑此节点GENERIC_WRITE具有此权限的用户可以重命名迭代节点。查看此节点GENERIC_READ具有该权限的用户可以查看此节点的安全设置。源代码管理权限特定于源代码文件和文件夹。您可以按以下方法设置这些权限：右击“源代码管理资源管理器”中的文件夹或文件，单击“属性”，在“安全”选项卡上选择要为其更改权限的用户或组，然后编辑“权限”中列出的权限。可以通过使用tf（源代码管理命令行实用工具）来设置这些权限。权限名称命令行中的名称说明读取tf: Read具有该权限的用户可以读取文件或文件夹的内容。如果用户对文件夹有“读”权限，则即使用户没有打开文件的权限，用户仍可以看到文件夹内容以及文件夹中的文件的属性。签出tf: PendChange具有该权限的用户可以执行签出并对文件夹中的项执行挂起更改。挂起更改的示例包括添加、重命名、删除、撤消删除、分支和合并文件。签入tf: Checkin具有该权限的用户可以签入项并修订任何提交的变更集注释。签入时将提交挂起的更改。加标签tf: Label具有该权限的用户可以对项进行标签。锁定tf: Lock具有该权限的用户可以锁定或取消锁定文件夹或文件。修订其他用户的更改tf: ReviseOther即使其他用户签入了文件，具有该权限的用户仍可以编辑该签入文件上的注释。取消锁定其他用户的更改tf: UnlockOther具有该权限的用户可以取消锁定其他用户锁定的文件。撤消其他用户的更改tf: UndoOther具有该权限的用户可以撤消其他用户所做的挂起的更改。管理标签tf: LabelOther具有该权限的用户可以编辑或删除其他用户创建的标签。操作安全设置tf: AdminProjRights具有该权限的用户可以设置这些文件和文件夹的权限。签入其他用户的更改tf: CheckinOther具有该权限的用户可以签入其他用户所做的更改。签入时将提交挂起的更改。&&&&&& 我遇到的80%的问题按上面的权限说明基本都解决了，认真摸索一下上面的那些权限，彻底了解了，tfs的权限大概就掌握的差不多了，本人也在摸索过程中。另外，提示一下，当在项目源代码中新建管理文件夹时，一定要注意“继承项目权限”项前面的勾要勾上，不然，会造成无人能添加该文件的管理成员的局面。这个问题难到了我们不少leader，呵呵，最后团队合作才发现了这个问题，大家一定要注意了，不然管理员也无能为力了。】&&&& 暂时总结一下，学习中，不断完善中。。。您所在的位置： &
VS11之代码评审
VS11之代码评审
在从Visual Studio 2010升级到Visual Studio 11后发现新的TeamExplorer界面中多出了一个Code Review & Requests功能区，这是Visual Studio 11提供的全新的代码评审功能。
　记得刚成为开发团队一员的时候，Team
Leader总是对我提交的代码逐行进行检查，确保没有重大问题后才容许提交进入代码库，在这过程中我的代码中很多缺陷被发现，有的缺陷非常复杂，并且是正常测试用例所覆盖不到的，这意味着一旦在生产环境中运行，可能会带来严重的后果。后来才知道这个过程叫做代码评审，随着开发经验的丰富，也经常对其他人的代码进行评审，这个实践在开发经历中一直得以保持。
代码评审最常用的方式就是文章开头提到的那样，由专人进行逐行查看，有的团队会采用团队集体评审的方式进行，但也都是基于手工操作的模式，其最大的问题就是效率比较低。当我把需要入库的代码交由Team
Leader评审的时候，不仅需要把整个工程打包并通过FTP传给他，还要准备一个预评审文档对本次提交的代码进行补充说明(注释经常不能详细说明一个复杂场景)，Team
Leader也不会立即对我的评审请求进行反馈，他通常在下班前才会做这件事，并且经常要把我叫到他的电脑旁进行询问，这个期间我常常在惴惴不安中度过。
在从Visual Studio 2010升级到Visual Studio 11后发现新的TeamExplorer界面中多出了一个Code Review
& Requests功能区，这是Visual Studio 11提供的全新的代码评审功能。
下面我们通过一个简单的场景来验证一下这个功能：
步骤1：开发人员Peter已经完成了一个功能点，在把修改过的代码检入TFS之前发起代码评审流程：
Peter需要选择哪几个评审人对他的代码进行评审，也可以根据某种条件由系统缺省指定;输入本次评审的名称以及描述等信息。
步骤2：评审人William会收到一封邮件，描述了本次评审的发起人，工作内容链接以及其他相关信息
步骤3：评审人William可以直接点击邮件中的链接，系统会自动打开Visual Studio集成开发环境，并定位到Code
Review标签页，他可以选择接受(Accept)或者拒绝(Decline)这个代码审查任务：
步骤4：William点击Accept后，开始审查代码
评审人可以点击Code Review中涉及的文件，看到了文件被修改的具体情况
评审人可以对其中的某一行代码添加注释
评审人也可以在对每个代码变更行添加注释后，写一个总的Review注释
完成评审后，评审人可以向评审发起人提交评审结果
步骤5：评审发起人Peter收到评审更新的邮件通知，看到评审人William的评审意见后进行相应修改，然后再将修改后的结果告知评审人。
Peter收到William添加注释的Code Review 通知，直接在邮件中打开链接进入Visual
Studio集成开发环境中看到William的注释
Peter点击第一个William的注释，可以看到注释所对应的代码行 - 第4行被高亮显示
Peter点击第二个William的注释，可以看到注释所对应的代码行&第10行被高亮显示
Peter根据William的反馈修改相应代码
Peter修改完成后，回复William的注释，告知意见被采纳
步骤6：评审人William收到评审意见已经被采纳的邮件通知，打开Visual
Studio集成开发环境确认Peter已经完成了相应修改，批准通过了本次代码评审工作;最终当所有评审人都批准了本次代码评审工作，评审工作发起人Peter可以结束本次评审。
William收到Peter回复注释的邮件，被告之修改意见被采纳
William批准通过了本次代码评审工作
Peter待所有审批人都完成代码评审后(本例中只有William一个评审人)，关闭此次评审请求【责任编辑： TEL：（010）】
关于的更多文章
Visual Studio 11是继Visual Studio 2010之后，微软下一代开发ID
本次的专刊为大家提供了Oracle最新推出的Java SE 8详细的开发教程，从解读到探究Java 8最新
8月第二周，开发者们每月必看的编程语言排行榜如期而
7月的名字叫“流火”！本周出差工作的各位辛苦了，因
程序员的30岁，是个伤不起的现象。你不可能敲一辈子的
本书译自Grails项目负责人Graeme Keith Rocher所著的“The Definitive Guide to Grails”一书，着重介绍了如何在Grails框架下使
51CTO旗下网站关于源代码管理内的插件选择问题，TFS总是会自动调到VSS上
前不久公司将所有的项目全部从VSS迁移到了TFS上,但是VS2010的插件设置成tfs之后会自动调成VSS，导致打开项目提示找不到关联信息。
有时VS2010打开一些项目的时候就经常出现问题，要打开好几次。
比如：打开VS2010之后，工具-选项-源代码管理-插件选择，这个地方我设置成TFS， 再打开项目，总是提示我 找不到关联信息，然后 是不受控制的临时工作，永久移除这几个选项，有时需要设置好几次之后，源代码管理的插件才不会自动调成VSS。
根据描述，请说明你们需要打开的项目是使用什么VS 版本创建的，打开项目的时候是什么样的错误信息。另外，是不是可以正常使用TFS管理项目。请按照以下方式尝试是不是这个问题可以解决：
1. 如果需要打开的项目不是VS2010的，请升级成VS2010的项目
2. 如果打开的项目是版本控制的，确保项目加入到版本控制
3. 在其他的电脑上尝试是不是可以正常打开项目
4. 如果TFS使用的是2010,请升级到TFS 2010 SP1。同时升级Visual Studio 2010到最新版本
请用以上方法确认这个问题是不是可以解决。如果仍然存在，需要更详尽的信息。
谢谢，We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
to participate the survey.
已标记为答案
根据描述，请说明你们需要打开的项目是使用什么VS 版本创建的，打开项目的时候是什么样的错误信息。另外，是不是可以正常使用TFS管理项目。请按照以下方式尝试是不是这个问题可以解决：
1. 如果需要打开的项目不是VS2010的，请升级成VS2010的项目
2. 如果打开的项目是版本控制的，确保项目加入到版本控制
3. 在其他的电脑上尝试是不是可以正常打开项目
4. 如果TFS使用的是2010,请升级到TFS 2010 SP1。同时升级Visual Studio 2010到最新版本
请用以上方法确认这个问题是不是可以解决。如果仍然存在，需要更详尽的信息。
谢谢，We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
to participate the survey.
已标记为答案
1，VS2010的项目，至于是什么版本创建的不太清楚。
2，受版本控制，以前是VSS控制的，前段时间整体迁移到TFS上的。
3，不是很清楚，有时间我用其他人的电脑测试下。
4，TFS2012。VS2010
再说下操作步骤啊：打开VS2010-源代码管理插件选择设置成TFS-回到VS首页打开项目-提示错误信息-再查看源代码管理的时候插件已经变成了VSS。
说明下：本身是有VSS插件，这个程序也是从VSS服务器迁移到TFS上的，但是现在问题在于插件选择TFS之后一直会自动跳到VSS。然后打开从TFS上下载的项目就会提示这个错误信息。
多打开几次是可以使用的
我认为可能是项目里面 有关VSS的绑定信息没有清除或者清除干净，导致每次打开项目的时候会自动判断成是VSS控制的项目。
请问下怎么清除项目内VSS的绑定信息？
Microsoft 正在进行一项网上调查，以了解您对 Msdn 网站的意见。如果您选择参加，我们将会在您离开 Msdn 网站时向您显示该网上调查。是否要参加？
<input type="hidden" id="hdnTrackerText" value="请不要关闭此窗口。谢谢！完成访问时，调查将显示在此处，所以请不要关闭此窗口。" />
其他 Windows 站点
来自西雅图的问候。