cvs 和 svn

2010-03-20 22:11

    这版本控制器其实就是为了让我们找工作面试的时候多一份筹码。

一，先说说cvs吧

CVS 操作:

1.查看当前文件不同版本的区别：

    # cvs diff -r1.3 -r1.5 file_name

2.查看当前文件（可能已经修改了）和库中相应文件的区别：

    # cvs diff file_name

3.对于上传的不是文本文件操作：比如：

    # cvs add -kb new_file.gif

    # cvs add -kb readme.doc

4.删除文件：

    # cvs rm -f file_name

    # cvs ci -m "why delete file"

5.环境变量添加：~/.bash_profile

    export CVSROOT=:pserver:chenchao@10.4.37.12:/home/cvsroot

6.tag标签的删除：（小心操作）

     # cvs tag/rtag -d release_1_0 <directory> //删除主干tag标签

   # cvs tag/rtag -B release_1_0_patch <directory> //删除分支tag标签

7.移动标签：

    例如，stable 标签现在是指向文件 backend.c 的版本 1.4 上，我们想将它指向版本 1.6 上面。 要移动一个非分支标签，在 cvs tag 或 cvs rtag 命令后面加上 `-F' 选项。 例如，可以这样做刚提到的任务：

    cvs tag -r 1.6 -F stable backend.c

    如果你明确要移动该分支标签，可以指定 -B 选项。 那样，给定名字遇到的非分支标签将被忽略并返回警告消息。

8.文件版本回退：

    用户希望取回一个不设置粘性标签的文件的老版本。 方法是在用 checkout 或者 update 的时候使用 `-p' 选项，使用该选项可以把文件的内容发送到标准输出。 例如：

    # cvs update -p -r 1.1 file1 >file1

    将把 1.5 版本恢复到 1.3 版本。

    # cvs update -j 1.5 -j 1.3 backend.c

    例如，假定你有一个叫 file1 的文件存在于 1.1 版本中，然后你删除了它（因此增加了一个 dead 版本 1.2）。 现在你又打算增加它，并用它原先的内容。 下面是如何操作的：

    # cvs update -j 1.2 -j 1.1 file1

9.打印文件的日志信息：

    # cvs log log.c

10.查看当前目录下文件的信息：

    # cvs status

    # cvs status file_name

11.添加特定信息到文件头内显示：

    /*

     * $Log$

     * $Id$

     * $Date$

     */

12.关于用户与权限：

这里是个有五个表项的例子 passwd 文件：

     anonymous:

     bach:ULtgRLXo7NRxs

     spwang:1sOp854gDF3DY

     melissa:tGX1fS8sun6rY:pubcvs

     qproj:XR4EZcEs0szik:pubcvs

（口令使用 Unix 标准的 crypt() 函数加密，因此它可以直接从常规 Unix /etc/passwd 文件粘贴过来。）

例子中第一行允许任何 cvs 客户机使用 anonymous 来访问，口令可以用任意字符还可以用空口令。 （这是一个站点允许匿名进行只读访问的典型用法；“只读（read-only）”部分信息的做法，参看 Read-only access。）

如果他们提供各自的明文口令第二、三行允许对 bach 和 spwang 进行访问。

如果她提供正确的口令第四行允许对 melissa 访问，但她的 cvs 操作将实际运行在服务器侧的 pubcvs 用户名下。 虽然系统上不须有 melissa 用户名，但 必须 使用 pubcvs。

第五行显示系统用户标识可以共享：作为 qproj 成功认证的任何客户实际将按 pubcvs 来运行，和 melissa 所做的一样。 用这种方法你可以在你的仓库中为每个项目创建一单个共享的系统用户，并且在 $CVSROOT/CVSROOT/passwd 文件中为每个开发者设置一行。 每行的 cvs 用户名应该不同，而系统用户名应该相同。 用不同的 cvs 用户名目的是在 cvs 将在其名字下记录其动作： 当 melissa 提交了项目中的一个修改，检入被纪录在项目历史中的 melissa 名下，而不是 pubcvs 下。 而共享一个系统用户的原因是可以安排仓库中相关区域的权限，只有那个帐户有写权限。

2 svn

SVN是一个版本控制工具，可以多人同时对一个工程进行操作，所以由此所产生的代码冲突和版本不统一也是在所难免的。那么，当面临这种问题时，我们应该怎么办呢？

老师说可能经常听到周围的人群在抱怨，为什么刚刚从服务器上下载的最新的Source总是有N多个Bug，是啊，抱怨不能解决任何问题，老实说那都是在写自己的代码之前没有取得最新Source，也就是说，可能在n天前的Source上进行更改i，然后上传至服务器上，所以别人写的东西也会被你莫名其妙的上传而覆盖掉，由此所产生的后果将是不可估量的。

因为这是老师亲身经历过上述事件，老师说记得刚进项目组的第一个周就遇到过这种问题，跟他搭档的同事犯了上述错误，所以我们知道，整个工程师一层层的嵌套，当这层编译不通过时，整个工程也是无法进行起来的，所以同事的责骂声，以及大家都闲下来没事干所费的工时等都是面前不可忽视的问题。

所以，为了避免以上问题的发生，我们应该及时下载最新的Source。然后再次基础上更改代码。当然及时不小心已经改以前的代码，那也应该在提交之前更新服务器最新版本，然后使用SVN所提供的Compare工具，将符合工程能够立于工程发展和前进的Source保留下来。这就是一个团队合作和交流的过程，你必须和周围同时开发的同事进行交流，取得最新的Source版本，如果不慎将以前废弃的Source保存下来，那罪过可就大了。

然后，也有一部分同志在平时改服务器上Source时，害怕自己的东西不慎改掉，又想回退到以前的版本，所以就会在自己的电脑上备份一份开发的Source，直到有一天自己也搞不准哪个是服务器上的还是自己本地的，所以就有可能导致错误的将本地的上传到服务器上引起不必要的麻烦。

学习总结：svn优哉游哉

所以，面对这种问题，我们要知道，SVN既然是版本控制软件，那他就能够很好的处理版本方面的问题，不要害怕自己的代码丢失之类的，这种问题完全可以通过回退Revert来返回之前的版本，来查看比较。