软件版本管理

管理员部分
• 维护用户列表(Maintain the User List)
– 添加用户(Add a User) – 更改密码(Change Passwords) – 创建用户列表(Create a User List) – 删除用户(Delete a User) – 编辑用户属性(Edit User Attributes)
签入、签出、获取、查看及相关操作 (Check In/Out、Get、View and Other Related Use)
• • • • • • • • 签入签出操作(Check In and Check Out Files) 撤销签出(Undo Check Out) 获取最近版本(Get Latest Version) 获取早期版本(Get Earlier Version) 获取和查看文件、工程(Get and View Files and Projects) 多人同时签出一个文件(Check Out Multiple Files) 排他性签出(Exclusive Check Out) 对工程的Cloak操作(Cloak Projects)
• 更高级别的安全控制 • 通过制定用户访问权限来实现的。
– 每个工程仅能被那些具有相应权限的用户访问到，每 个命令仅能被那些具有相应权限的用户使用
普通用户部分
• • • • • • • • 对工程、文件的一般性使用 打开/关闭数据库(Open/Close a Database) 创建新工程(Create New Projects) (Create 添加文件、目录、工程 删除和恢复文件、工程 移动文件和工程(Move Files and Projects) 重命名文件、工程(Rename Files or Projects) 设置工作目录
• Cloak：若对某工程实行了Cloak操作，则当对该工程的上 一级工程进行Get/Check In/Check Out/Undo Check Out/Project Difference操作时，将不会影响该工程及其子 工程。而在该工程上进行类似操作时，则和平常得到的结 果一样。这一属性将传递给其下的子工程 • Pin：对共享文件很有用，尽管它的使用不仅限于共享文 件，也包括其他任何文件。当你对一个文件实施Pin操作 后，你将不能对之做任何修改。如果一个文件在Pin之后 又被实施了Share操作，而被Pin的那个版本同时也是被共 享的版本，则所有共享该文件的工程都不能更改该文件
普通用户部分（续）
Branch、Share、Label和Pin操作
• 通过Share操作，一个文件可以被多个项目共享， 在任何一个项目中对该文件的更改，都将反映到 其他相关项目里。 • Branch操作则消除这种共享，每次将一个被共享 的文件拆成两个分支 • 给文件、工程指定标签(Label Files and Projects)
• VSS也支持多个项目之间文件的快速高效的共享
– 每个成员对所有的项目文件所作的修改都将被记录到数据库中， 小组的成员可能得到该项目的最新版本，对它进行修改，并保存 一个新的版本
• VSS可以很容易地其他的开发工具集成在一起
– 一旦VSS集成到开发环境中，就可以象控件一样使用，能够很好 地体现出VSS的易用性和强大功能
管理员部分（续）
权限(Rights)
• 权限的传递(Rights Propagation) • 安全访问权限(Security Access Rights) • 缺省安全设置
– 当添加新用户时，你只有两种级别的访问权限可供选 择：
• 只读权限（Read-only rights）： • 可读写权限（Read/write rights）：
问题具体化
• 1. 怎样对研发项目进行整体管理 整体管理； 整体管理 • 2. 项目开发小组的成员之间如何以一种有效的机 制进行协调 协调； 协调 • 3. 如何进行对小组成员各自承担的子项目 子项目的统一 子项目 管理； • 4. 如何对研发小组各成员所作的修改 修改进行统一汇 修改 统一汇 总； • 5. 如何保留修改的轨迹 保留修改的轨迹，以便撤销错误的改动； 保留修改的轨迹 • 6. 对在研发过程中形成的软件的各个版本如何进 行标识，管理及差异识辨 标识， 标识
出现的版本控制问题
• • • • • 代码管理混乱 代码管理 解决代码冲突 代码冲突困难 代码冲突 在代码整合期间引入深层BUG 无法对代码的拥有者进行权限控制 权限控制 特别是对产品 产品的开发，你会频繁的进行版本发布， 产品 这时如果没有一个有效的管理产品版本 管理产品版本的工具， 管理产品版本 一切将变得非常艰难
具体应用
• • • • 假定 我们项目的2.0版本刚刚完成 项目开发小组继续朝着3.0版本前进 试用项目维护人员需要一个临时的2.1版本 来修改试用过程中发现的bugs
• 将当前项目加上标签(Label)--Version 2.0 • 继续在该项目上进行修改，开发新的版本 • 这个时候在版本2.0的试用过程中发现错误，你需要一个临时的版本 来修改错误同时又不影响版本3.0的开发 • 选择Tools菜单，单击Show History显示Project History Options对话 框 • 选中Include Labels复选框 • 单击OK显示History of Project对话框 • 选择加有标签"Version 2.0"的版本 • 单击Share显示Share From对话框 • 选择将要产生的项目的父项目，我们选择$/。 • 单击OK显示Share对话框 • 将此项目命名为bugfixAfterV2.0，单击Close退出History of Project对 话框 • 操作完成后会发现在VSS中增加了一个项目$/bugfixAfterV2.0 • 选定那些你确实需要修改的文件，然后进行分支操作 • 这样你就可以任意修改这些文件，而且你会发现图标也恢复到原来的 样子
管理员部分（续）
清除临时目录(Clean Temporary Folder )
• VSS通常在运行时把临时结果放在临时目录里， 并在退出前将之删除 • 由于某些原因，例如非正常重启，可能导致临时 内容残留在目录中 • 当没有任何用户运行VSS或VSS Administrator时， 请清除临时目录的内容
• 我们必须要引进一种管理机制，一个版本 管理机制，而且是广义上的版本管理，它 不仅需要对源代码的版本进行管理，而且 还要对整个项目进行管理 • 使用版本控制工具
主流版本控制工具介绍
• • • • • Starteam PVCS Version Manager ClearCase(CC) CVS（Concurrent Versions System） （ ） Visual SourceSafe（VSS）
– 当使用Label功能时，表明你在所选工程的历史记录里 创建了一个新的版本
• Pin操作(Pin)
– 当你对一个文件实施Pin操作后，你将不能对之做任何 修改 普通用户部分（续）
Visual SourceSafe支持并行开发 支持并行开发
• 需要并行开发的情形
需要并行开发的情形
• 所做的工作涉及到许多文件 • 其它的小组成员占有了你希望处理的文件 • 想修改项目早期版本中的某个bug
VSS中的几个重要概念
• 项目
– 所谓的项目是一组存在VSS中的文件，可以在项目中 或是项目之间进行文件的添加、删除、编辑和共享。
• 工作目录
– 用户真正对项目文件进行调试修改的地方 – 当用户Checkout 或提取一个文件时，VSS将该项拷贝 到用户的工作目录下 – 当用户修改了该文件并将其Checkin 签入时，VSS再将 它从用户的工作目录拷回到VSS的数据库中 – 在用户作Checkout 签出时，VSS将会自动管理他的工 作目录，诸如创建必要的子目录，而且工作目录可以 随时创建或修改
软件版本管理
报告人： 报告人：刘全明
2011-6-1
内容
• 版本管理的必要性 • 版本管理工具 • Visual SourceSafe如何支持并行开发 如何支持并行开发
版本管理的必要性
• 软件项目完全由一个人来完成是难以想象的，通常是有一 个研发小组 研发小组来共同分析、设计、编码和维护 研发小组 • 许多因素都有可能导致对软件的修改 修改，小的可能只是对某 修改 个源文件中的某个变量的定义改动，大到重新设计程序模 块甚至可能是整个需求分析变动 • 由于软件开发所固有的特征，可能会形成众多的软件版本， 而且我们并不能保证不出现错误的修改 并不能保证不出现错误的修改 • 必须进行版本管理
• 以往的那种被誉为具有良好编程风格 良好编程风格的做法，诸如在对他 良好编程风格 人的源程序进行修改时注释修改原因，修改人和日期，如 果是多个成员同时进行了修改，那么需要进行及时的人工 的差异比较和综合以便形成一个统一的新版本 • 这种做法在当前的大型软件的开发中已经越来越没有空间 了，可以说是一种以小作坊 小作坊的形式来面对软件的社会化大 小作坊 生产，再也不可能行得通了 • 出现版本控制问题
数据库打包/恢复(Archive / Restore Databases）
• • • • 定期地备份VSS数据库，或者数据库的某一部分 节省VSS数据库服务器的磁盘空间 加快显示历史记录操作的速度 便于在多个VSS数据库间传递文件和工程，保持 历史记录完整无缺。 • 备份全部或部分VSS数据库内容并压缩成文件。
Visual SourceSafe
• VSS是一种版本控制管理工具 • 可以有效地管理工程 • 简单易用、方便高效、与Windows操作系 统及微软开发工具高度集成
VSS的简单工作原理
• 将所有的项目源文件（包括各种文件类型）以特有的方式 存入数据库 数据库
– 开发组的成员不能对该数据库中的文件进行直接的修改，而是由 该版本管理器将该项目的源程序或是子项目的源程序拷贝到各个 成员自己的工作目录下进行调试和修改，然后将修改后的项目文 件作Checkin提交给VSS，由它进行综合更新
处理方法
• 你选择一个分支流就可以避免经常打乱别 人的工作。同时你可以将所有的工作测试 完后再将它们集成到你的项目中。 • 要求：项目规定你不能够在主线上工作。 相反地，项目被分成许多小的部件，每个 部件是一个分支，只有该部件完成后，才 会将它合并到主线中。
文件共享(share files)
• 在VSS的数据库中有且仅有文件的唯一拷 贝--主控拷贝(master copy)，因此共享文件 也就是在不同的项目里建立了指向该主控 拷贝的链接。 • 如果你在其中一个项目中改变此文件，那 么其他项目中所有的共享也随之改变。此 外，如果选择共享某个项目中的所有文件， 我们也可以称之为共享该项目
Leabharlann Baidu
文件归并(merge files)
• 所谓文件归并就是将由一个文件产生的多个不同 拷贝重新形成一个唯一的新的文件版本，一般都 是将分支上的改变反映到主线上，所以称之为归 并操作 • 在文件归并过程中VSS并不能去决定文件差异的 取舍，它只是将这些文件间的异同提交给你，由 你自己来确定最后的文件内容。当然比较的基准 就是我们前面提到的它们共同的祖先 • 投送者(contributor)，目标(object) • 演示
文件共享(share files)
• 演示 • 文件共享机制可以减少数据库中文件的数 量，能够实现文件的重用
分支操作(branching)
• 与共享操作不同的是，分支操作实际上是 将文件放在不同的项目中来实现完全的独 立性，此时在一个项目中的文件修改不会 影响到其他的项目中的文件 • 共享操作后形成的位于不同项目里的两个 文件拥有一个共同的祖先，也就是他们的 历史(history)记录是从同一点分离出来的 • 演示