有人说TFS是VSS的升级版，其实不是的，二者区别还是很大的。特别是取消了share等功能，让TFS在代码管理上更像SVN、CVS了。微软最喜欢抄袭别人了。
Visual Source Safe 是用于软件专业开发人员的源代码管理工具
Team Foundation Server是为开发团队提供集成源代码管理、问题跟踪和进程管理的更改管理系统
相同点
1.同时开发产品的多个版本
2.在不影响其他版本的情况下对产品的一个已发布版本进行更改
3.快速检索一批相关文件，确定做出更改的用户和时间
4.比较文件的两个版本以及将更改从一个版本移至其他版本
5.都提供了命令行客户端和Visual Studio 2005 集成
不同点
1.结构区别
VSS
VSS 是仅包含客户端的源代码管理系统
它的客户端（如SourceSafeExplorer 和用于Visual Studio的插件）读写VSS 数据库，该数据库是通常存储在共享网络文件夹中的文件集合
TFS
Team Foundation 是客户端-服务器源代码管理系统，它使用.NET Web 服务访问存储在SQL Server 数据库中的项
Team Foundation 源代码管理的体系结构提高了性能和可靠性
2.安全和项目权限
VSS
在VSS 管理器程序中设置的VSS 用户权限和分配与对VSS数据库文件夹的Windows 共享权限无关
TFS
在Team Foundation 中，用户特定的操作权限和项目级别访问权限受Windows 用户帐户的限制
由Internet Information Server 安全地执行用户身份验证。
单独访问SQL Server 数据库的权限无需赋予执行源代码管理操作的个别用户。
因此，这样产生的Team Foundation 安全结构安全、可靠并易于管理。
3.可靠性
VSS
由于VSS 没有服务器组件，因此涉及将数据从客户端传输到数据库的操作是非事务性的。这意味着如果发生问题，操作就无法回滚
TFS
Team Foundation 是客户端-服务器应用程序，该应用程序利用不会受到网络连接问题影响的存储过程在数据库中执行写入操作。此外，还使用事务执行某些操作，以便在这些操作出错时可以回滚
4.可伸缩性
VSS
建议的团队人数是二十或更少
数据量建议的大小限制是4 GB
TFS
Team Foundation 最多可支持五百名用户的团队
Team Foundation 服务器包含的数据量可达到SQL Server 数据库允许（千兆字节）且您的硬件可支持的最大数据量
5.功能差异
Team Foundation 中存储历史记录的方式的不同之处
添加和创建
在VSS 中，添加一个文件或文件夹时，会创建该文件及其父级的一个版本。在该父级历史记录中，该操作被记录为“添加”；而在该文件历史记录中，该操作被记录为“创建”
在Team Foundation 中，添加一个文件或文件夹时，将只用“添加”操作创建该文件或文件夹自身的一个版本。不为此操作创建父级版本。
重命名、删除和撤消删除
在VSS 中，这些操作会创建父级的新版本
在Team Foundation 中，这些操作创建该项自身的一个新版本
移动
在Visual Source Safe 中，在移动某一文件夹时，将同时创建源和目标父文件夹的新版本，并对每个父级记录将该文件夹移入或移出父级的操作
在Team Foundation 中，“重命名”操作只创建F 的新版本。
VSS 中不存在的Team Foundation 功能
工作区
变更集
搁置集
Team Foundation 工作项
签入策略
签入说明
通过设置警报执行的电子邮件通知
Team Foundation 中不存在的VSS 功能
共享
固定
存档和还原
销毁
关键字扩展
在本文的两个部分中，我将介绍Team Foundation Server的一些核心特征，重点介绍在本产品的日常应用中是如何将这些特性结合在一起使用的。
作为一名软件开发人员，在我的职业生涯中，我经常会用到支持软件开发过程的大量开发工具，如版本控制工具、漏洞跟踪包、生成脚本语言、单元测试框架 和需求分析工具等等。在.NET平台上，大量的支持工具能够很好地独立工作，但是，为了使得各种工具之间都够互相协作，还是经常需要一些手动工作。
随着Visual Studio产品线中Team Foundation Server组件的发布，微软使得开发团队在僵化的软件工程实践应用中取得了巨大进步。这并不是因为该产品包含的各种新增特性一定是最好的，关键因素是它的集成性。
Team Foundation Server 起步
Team Foundation Server(TFS)是这样一种服务器产品，它需要部署到软件开发环境中，这样开发人员就可以使用它提供的各种服务。因为TFS是设计用于大规模团队，因而有两种拓扑结构供选择：双服务器和单服务器。
在单服务器部署中，TFS被安装在Windous 2003 server上，且该机器上已安装了SQL Server 2005数据库服务器、Web服务器IIS以及windows SharePoint Services。这种类型的安装可以满足大量用户需求，并且适用于大部分条件。
双服务器部署将SQL Server 2005 的数据库引擎和分析服务组件分开安装在不同的机器上，这样就可以实现可扩展性（通过增大用于大量用户注册操作的空间以及将处理负载的不同数据仓库安装在不同的机器上实现，这种机器最大可达64位。）
安装了TFS服务器后，客户端可以通过安装Team Explorer来访问服务器。Team Explorer是一组组件，它包括简单版本的Visual Studio 2005（如果是在已经安装了Visual Studio 2005的机器上就仅仅是再添加更多功能）和大量用于微软的Excel和Project的插件，利用Excel和project可以访问存储在Team Foundation Server数据库中的数据。
Team Explorer可用于访问Team Foundation Server的以下特性：
- 过程引导
- 工作项跟踪
- 版本控制
- 自动生成
- 报告
创建一个团队项目
在开发团队可以使用Team Foundation Server之前，必须先创建一个团队项目，团队项目代表了一个所有团队活动都在这里发生的管理单元。为了创建一个团队项目，Team Foundation Server管理员需要打开Visual Studio 2005和 Team Explorer工具窗口（从视图菜单）。当打开Team Explorer 窗口后，就可以建立一个到服务器的连接。
右键单击树状视图中的服务器节点，TFS管理员就可以选择“新建团队项目”。事实上，这个选项通常是隐藏的，可见需要新建一个团队项目的情况是很少的。绝大部分情况下，一个软件开发团队在一个大型软件的生命周期中仅有一个团队项目。
创建团队项目时，开发小组需要做的第一件事情是决定使用那个开发模型。
选择开发模型
Team Foundation Server允许开发小组选择他们想要使用的任何特定软件开发方法。下面的列表中提供了两种开发模型：
- 敏捷模型驱动软件开发
- 能力成熟度集成模型软件开发
每个开发模型都有一组特有的定制特性，包括定义工作项（要做的事情、要确定的事情、需求等等），过程管理和报告。下表显示了两个默认的开发模型中不同工作项的分解：
敏捷模型驱动软件开发
能力成熟度集成模型软件开发
漏洞
服务要求的质量
风险
场景
任务
漏洞
改变请求
问题
需求
回顾
风险
任务
在这种情况下即使工作项的数目和名称存在差异，也应该指明使用这两种开发模型通用方法，而不是开发小组来推测他们该如何使用这些工作项类型，开发模型可以包含一些可选的过程管理页面。
如果对话框中的模型不适合你的具体要求，可以订制它们以满足你的要求。事实上，已经有大量可以获得的第三方开发模型，如Scrum and process MeNtOR。
访问工作项存储器
创建了团队项目后，开发小组需要做的第一件事是分解已经创建的初始工作项集。这些工作项帮助开发人员完成一系列可以使得软件项目成功开始的活动，并 且依据不同的开发模型选择不同的工作项。通过展开团队项目节点，就可以看到工作项文件夹，继续展开然后打开查询文件夹可看到全部或部分工作项。
书写定制得工作项查询
最后需要书写一个新的工作项查询列表。新定义的查询可以放在“团队查询”和“我的查询”这两个文件夹的任何一个。团队查询是一个可被项目小组中的所有开发人员访问的全局可访问容器，我的查询是一个由每个程序开发员所有的私有查询集。
我经常使用的一个有用的查询是Recycle Bin query，这个查询可用于打开最近关闭又需要重新打开的工作项（偶然关闭工作项的情况时有发生）。第一步是从工作项节点的背景菜单中选择“添加查询”。
在查询编辑器打开后，简单的用户接口就可以基于某些简单的表达式从工作项列表中过滤出需要的项目。在上面的情况中，查询设置为返回当前状态为关闭的团队项目中的所有工作项。
应用Team Foundation Server 的版本控制
访问了工作项，就可以应用Team Foundation Server中的版本控制。像TFS中的其它特征一样，版本控制功能位于SQL Server 2005之上，用于提供良好的性能和可扩展性（实际上，宿主在TFS中的版本控制存储器的大小估计有千兆字节。开发小组可能遇到的第一个与版本控制相关的 工作项是迁移已经存在的源代码，这个工作项提供了在迁移源代码是需要做什么的详细视图。
配置一个工作区
在程序员将文件添加到版本控制存储器之前，需要将版本控制存储器的逻辑结构映射到本地机器上的文件系统。Team Foundation Server 引入了工作区的概念。工作区是物理位置和文件系统间的一组映射，一个文件系统与一个特殊用户和计算机组合相匹配。在文件上进行工作的程序员，他们是逻辑的 进出工作区。为了建立一个工作区，程序员需要双击Team Explorer中的源码控制图标，到工作区下拉菜单。
我发现将整个源代码树的根映射到本地驱动器上的一个具体位置并将其作为唯一映射是最简单的方法。我自己的方法是在我的数据驱动器的根目录上创建一个 “沙盒”目录，在它的下级有一个子目录，将其命名为我连接到的TFS服务器的名字。（我连接到了多个TFS服务器，因此一定要注意避免混淆）。
建立了映射之后，浏览源代码控制浏览器将会列出源代码树上逻辑位置的本地路径。至此你就可以添加源代码到这个容器中。
程序员面对的一个局限是他们不能将文件添加到版本控制存储器的根中（$/），且所有以及文件夹都直接和某个特定团队项目相关。这里面的逻辑是，一个 Team Foundation Server可用于大量项目，每个项目应该在它们自己的区域内工作。
添加源代码到Team Foundation Server
在Team Foundation Server中安排源代码有无数的方式，你为什么选用这种而不用另一种，详细的原因说明超出本文的范围。下面选择的方式仅是一个用于演示例子。特别的地方 是，我选择添加了三个字文件夹：Trunk, Branches 和Releases，如下图。
文件夹添加到版本控制系统后，其他的程序员并不会立即看到，他们必须像文件一样进行注册。在本例中，在注册前我将添加一组解决方案和项目文件到这个容器中，然后一起注册。
除了增强了性能和扩展性外，TFS将其版本控制系统安装在SQL Server 2005上，这意味着，进行原子提交和注册的方法是可能的。也就是说，要么全部注册成功，要么全部失败。注册可以在源代码控制浏览器或解决方案浏览器上执行（或者在强制改变工具窗口中进行）
版本控制系统和工作项存储器在注册时集成在一起。当注册时，可以将其与一个或多个工作项关联。例如，因为这是刚引入源代码，所以我可以浏览注册对话 框中的工作项视图，选择工作项3387和它关联。注意当关联工作项时无论默认的选择如何都要将注册行为设定为 “解决”，这样做的目的是防止任务关闭工作项，因此较早建立十分有用的Recycle Bin 查询。
建立一个注册，就叫做一个改变集，一个源代码容器不过是一系列不断彼此堆积起来的改变集。因为在数据库中改变集是一个可以区分的实体，因此可以将数 据和它关联在一起，所以上面建立的改变集和工作项3387的关系可以在改变集中浏览或者在工作项中浏览。下面的屏幕截图显示了连到工作项的改变集。
新概念：搁置集
和Team Foundation Server中的版本控制相关的一个新概念是搁置集。搁置集的思想是程序员在过周末休息时，可以将在工作日做的改变放在某个安全的地方。建立一个搁置集相 当简单，首先，程序员在解决方案浏览器中的背景菜单中选择“搁置必要的改变”，然后出现下面的对话框。
程序员可以给搁置集一个名字，以便以后可以查找和恢复它，和注册对话框一样，搁置集也可以添加评论和关联工作项。搁置集仅包含修改过的文件，因为改变集版本是从版本控制存储器引出的，所以创建他们的相当简单。
为了恢复搁置集，可以选择背景菜单中的“解冻必要改变”选项，程序员可以查找由他们或其他程序员建立的搁置集。
事实上搁置集可以共享，这意味着它们可以很好的执行代码预览，增强单注册点策略，这对一个特别项目在封装时可能很十分有用。
在本文的下一部分，我将详细介绍搁置集，TFS中完善的分支支持，TFS是如何支持自动生成的并介绍一下报告功能提供的功能。
两个帖子的原文：
http://hi.baidu.com/trh87/blog/item/a561082409cb2f34c9955922.html
扫一扫
278
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
