7.7. 删除和反删除

7.7.1. Starteam文件存放机理
7.7.2. 删除
7.7.3. 移动
7.7.4. 反删除的步骤

删除和反删除文件是 Starteam 和 CVS 最大的不同点之一。如果处理不好,虽然 不会造成信息丢失,但处理方式不擅,将给 starteam 服务器端引入过多的数字 垃圾。

原则是:

7.7.1. Starteam文件存放机理

STARTEAM以数据库为核心,是面向工程的管理方式。版本控制文件的文件名 由数据库管理,文件名不过是"指针"。方便文件在一个工程甚至同一个 Server Configuration的不同工程中的共享,以及任意移动和组织。

CVS,Perforce以文件为核心,即面向文件的管理方式,文件可以方便的重新 组合以及移植。原子化的Check In、二进制文件的版本控制是更Perforce的优势。 但是缺点是很难完成一个工程中,文件的移动及文件改名给前后不同版本/分支带来 问题;不当处理或者丢掉以前版本控制中的文件部署,或者增加由于文件冗余增加 占用空间。

STARTEAM的不利因素是很难将一个工程或者Server Configure中的文件分离、 组合、单独移植。其数据仓库 Repository像一个黑盒子,所有Project的所有版本 控制文件,都放在同一个目录下(Vault/Archive目录下,这是starteam的不足)。 目前缺乏良好的文件管理工具,是一个缺憾。

Starteam 一旦对文件进行版本控制,就丢入 Repository 目录中,很难在从中删除。 这应当看作是其最大的 BUG。

7.7.2. 删除

无论文件从哪个视图(根view,子view)添加目录和文件到starteam,在 该view下显示的文件夹和文件只不过是Vault/Archive目录下文件(以流水号作为 文件名),在数据库(starteam的管理核心)中的一个"指针",删除文件,不过是 删除了"指针",虽然没有真正删除文件,但是如果数据库中的所有关于某个文件的 "指针"都删除,文件只能通过历史来查看。但可以通过适当方法,通过历史的 "指针"重新找回版本控制。

7.7.3. 移动

文件在同一个视图中移动时,历史被保留;但当文件在不同视图中移动(注意不是删除) 时,原视图即使在历史中也找不到该文件,该文件从该视图中彻底消失了。如果将 一个视图彻底删除,如果该视图下文件没有在其他视图中建立共享的话,则造成文件 丢失,无法找回。

为防止此类事故的发生,经常备份,并设置任何人都没有工程和视图的删除 权限。

7.7.4. 反删除的步骤

  1. 同时打开当前视图和删除文件之前的视图,拷贝历史视图的文件到当前视图。

    image

  2. 设置新视图中历史文件的属性。

    image

  3. 设置新视图中历史文件的属性。由历史reversion的只读版本修改成为 Floating 版本即可。

    image