Visual SourceSafe6.0 使用指南(一) (转)

最新推荐文章于 2010-04-19 19:50:00 发布

csd3176

最新推荐文章于 2010-04-19 19:50:00 发布

阅读量482

点赞数

文章标签：数据库开发工具

Visual SourceSafe6.0 使用指南(一) (转)[@more@]

Visual sourceSaft6.0 使用指南

Leafinwind

XML:namespace prefix = o ns = "urn:schemas-microsoft-com:Office:office" />

1 Visual SourceSafe的简介

Visual SourceSafe是微软出的一个支持团队协同开发的文档版本管理工具，现在已经在Visual Studio6.0和Visual Studio.NET等集成开发工具中。

他的特点主要是用户易用性好，可视化程度高，通过网络共享来实现局域网内的文档共享，比较适用于小团队开发的文档代码的版本管理。

2 程序组简介

Visual SourceSaft给用户提供了四个管理工具，如下图所示：

CVS_progroup.jpg" align=baseline border=0>其中：

Visual SourceSafe6.0 Admin程序的主要面向项目CVS管理员，主要进行的工作有用户管理，VSS数据库管理，工程权限管理，数据库备份管理以及数据库中的一些缺省设置的管理。^_^，可以让你找到网管的感觉，想踢谁就踢谁，不过要记住“权力越大，责任也越大”。

Microsoft Visual SourceSafe 6.0程序是主要面向程序员，用于日常的文档代码的检入（checkin）、检出(checkout)工作和文件版本管理工作，这也是最常用的一个程序，也是很弱智的，当然，是弱智都能使用的工具，这是MS的特点。

其他的两只主要是在某些异常情况发生后（如checkin文件时，服务器死机）进行一些数据库的错误检查和修复的工作。如Analyze VSS db用来分析检查数据库的好坏，而Analyze & Fix VSS DB在前者的基础上还增加了数据库修复的功能。我一次也没用过，不好多说。

3 文档版本管理的一些基本概念

3.1 文件的服务器版本(受控版本)和文件的本地版本(不受控版本)：

在刚使用的SourceSafe等类似的文档版本控制软件的时候，要首先明确这两个概念。许多刚开始使用文档版本软件的人员往往没有这些概念，特别时某些单机板的版本控制软件，往往给人的感觉时版本管理软件直接控制了本地文件，记录了它的修改过程和文件的版本。其实非也，在使用版本控制软件的时候，我们一定要明确文档的两个版本，就是单机版的软件也是要两个版本分开理论的。

一个是文件的服务器版本，这个版本绝对是个受版本管理软件保护和管理的版本，用户只能通过管理软件授权的有限操作来影响和改变这个版本。同时，还要强调的是这个版本也是一个共享的版本，有系统授权的用户均可以访问。

一个是文件的本地版本，这是一个不受版本管理软件控制的版本。我们不能直接修改文件的服务器版本，但可以直接修改本地文件。哈哈！对本地的文件，你享有一切权力。

不过这里要强调的一点就是要建立以服务器的文件为中心的概念。

3.2 版本控制软件的基本工作流程和原理

1. 首先，用户A获得服务器上文件F的一个最新版本，比如版本8，将其下载(DOWNLOAD)到本地，形成文件的本地版本。

2. 然后在本地修改文件

3. 本地文件修改完毕后，用户A向服务起提交(UPLOAD)文件修改，并更新文件F的版本到9。

4. 接着，用户B也开始下载文件F的最新版本，这时他获得版本的则为9。这样，用户B所得到的文件就包括了用户A的修改。

5. 接着重复上述过程，在服务器上形成文件F的版本10。这个版本10中就包含了用户A和用户B的修改。

我们可以看到版本控制软件使用的基本流程，这也是保持每个用户的修改得以提交和扩散的机制。起过程图示如下：

由上面我们可以看到文件版本控制软件的基本工作原理就是每个用户从服务器来获得文件的某个版本，并立足于这个版本来作修改，修改完毕之后向服务器来提交自己的修改。而服务器通过其自身的版本管理机制了控制和融合每个用户的修改提交，并形成该文件的新的版本，并共享之。

3.3 文件锁

那么上面的提到的流程中，如果用户B在用户A在完成步骤3的提交之前，就下载了文件F的文件版本，显然它下载的是版本8，里面没有用户A的修改。如果在A提交修改后用户B也提交了修改形成版本10，则版本9中存有用户A的修改，而版本10中只有用户B的修改，最新的版本10中丢失了用户A的修改，这样会造成用户修改数据的丢失。造成这样修改数据丢失的原因一言以蔽之，就是多个用户在文件的同一个版本上作修改，造成提交的时候，所形成的最新的文件版本中会丢失某些用户的修改。如下图所示：

那么怎样避免这样的情况的出现，有的功能强大的版本控制软件采用了复杂的版本冲突检测和融合技术。有的比较简单管理软件采用了文件锁技术。简单的说，文件锁技术可以让一个用户独占式的修改服务器端文件的一个版本。

这是怎样实现的了，在Visual SourceSafe中就是靠检入(CheckIn)和检出(CheckOut)这对操作实现。Checkout就是在服务器端对文件加锁，CheckIn就是提交修改并对文件解锁。当要一个用户打算要修改一个文件的时候，其流程如下：

1. 用户A检出（Checkout）文件F，并给文件加锁，下载文件最新版本8

2. 用户A在本地修改版本8的文件

3. 用户A完成修改，向服务器提交修改，形成文件F的最新版本9，并同时将服务器的文件F解锁

4. 文件F在解锁后的才能有用户B检出加锁，这是用户B就下载了包含用户A修改的版本9

5. 重复上诉过程。

由于一个文件只能被加锁一次，显然，则在用户A检出(Checkout)这个文件之后，检入(CheckIn)之前，用户B的所有的Checkout操作都会失败。这样就保证了上面流程，也保证了用户A和用户B的修改的串行性和修改数据的完整性。

有上面的图可以看出，对VSS系统的用户客户端主要操作两个地方的文件，一个是服务器上的文件，一个是本地存放要修改编辑文件的目录。一般来将，文件版本管理系统不会给客户端直接暴露服务器端文件存放的物理路径，而只会给一个虚拟的逻辑路径，在VSS中，没有数据库的虚拟路径的根都是“$/”,然后没有项目目录都按照树形结构挂接在这个根的下面。我们将项目的这个虚拟目录叫做服务器目录。而在本地存放临时修改文件的物理目录叫做工作目录。显然，我们要将这个每个项目的虚拟目录和本地工作目录对应起来，这样才能顺利的在服务器和本地之间交互文件。

3.5 VSS中的最常用版本操作

Get Latest Version：同步操作，仅仅从服务器上获得最新版本的文件

Check Out：加文件锁，默认情况下会包括Get Latest Version操作.

Check In：解文件锁，同时提交本地的修改。

好，有了上面一些基本的文件版本管理的一些基本概念，则在下文中讲到一些基本操作时就不会有太多的迷惑。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-991636/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10752043/viewspace-991636/