开始学习啦...........

SVN related

上一篇 / 下一篇  2011-06-17 11:33:33

TortoiseSVN 的 403 Forbidden错误

Server sent unexpected return value (403 Forbidden) in response to OPTIONS

用TortoiseSVN用同一个https网址访问版本库始终出现server sent unexpected return value(403 forbidden)in response to options…… ,察看了下apache的ssl错误记录,发现原来是指定了DocumentRoot的缘故。在ssl.conf中注释掉DocumentRoot这一行就可以了。http也是一样的,如果你配置了虚拟主机,就不能指定该ServerName的DocumentRoot。


  • svn 中tag branch trunk 的用法

    2010-05-25 11:37:02

    在SVN中Branch/tag在一个功能选项中,在使用中也往往产生混淆。

    在实现上,branch和tag,对于svn都是使用copy实现的,所以他们在默认的权限上和一般的目录没有区别。至于何时用tag,何时用branch,完全由人主观的根据规范和需要来选择,而不是强制的(比如cvs)。

    一般情况下,
    tag,是用来做一个milestone的,不管是不是release,都是一个可用的版本。这里,应该是只读的。更多的是一个显示用的,给人一个可读(readable)的标记。
    branch,是用来做并行开发的,这里的并行是指和trunk进行比较。

    比如,3.0开发完成,这个时候要做一个tag,tag_release_3_0,然后基于这个tag做release,比如安装程序等。trunk进入 3.1的开发,但是3.0发现了bug,那么就需要基于tag_release_3_0做一个branch,branch_bugfix_3_0,基于这 个branch进行bugfix,等到bugfix结束,做一个tag,tag_release_3_0_1,然后,根据需要决定 branch_bugfix_3_0是否并入trunk。

    对于svn还要注意的一点,就是它是全局版本号,其实这个就是一个tag的标记,所以我们经常可以看到,什么什么release,基于xxx项目的 2xxxx版本。就是这个意思了。但是,它还明确的给出一个tag的概念,就是因为这个更加的可读,毕竟记住tag_release_1_0要比记住一个 很大的版本号容易的多。

    branches:分枝

    当多个人合作,可能有这样的情况出现:John突然有个想法,跟原先的设计不太一致,可能是功能的添加或者日志格式的改进等等,总而言之,这个想法可能需 要花一段时间来完成,而这个过程中,John的一些操作可能会影响Sally的工作,John从现有的状态单独出一个project的话,又不能及时得到 Sally对已有代码做的修正,而且独立出来的话,John的尝试成功时,跟原来的合并也存在困难。这时最好的实践方法是使用branches。 John建立一个自己的branch,然后在里面实验,必要的时候从Sally的trunk里取得更新,或者将自己的阶段成果汇集到trunk中。

    (svn copy SourceURL/trunk DestinationURL/branchName -m "Creating a private branch of xxxx/trunk." )

    trunk:主干

    主干,一般来说就是开发的主要呆的地方,


    tag:
    在经过了一段时间的开发后,项目到达了一个里程碑阶段,你可能想记录这一阶段的代码的状态,那么你就需要给代码打上标签。

    (svn cp file:///svnroot/mojavescripts/trunk file:///svnroot/mojavescripts/tags/mirrorutils_rel_0_0_1

    -m "taged mirrorutils_rel_0_0_1")

    另有一说,无所谓谁对谁错。

    trunk:表示开发时版本存放的目录,即在开发阶段的代码都提交到该目录上。

    branches:表示发布的版本存放的目录,即项目上线时发布的稳定版本存放在该目录中。

    tags:表示标签存放的目录。

    在这需要说明下分三个目录的原因,如果项目分为一期、二期、三期等,那么一期上线时的稳定版本就应该在一期完成时将代码copy到branches上,这 样二期开发的代码就对一期的代码没有影响,如新增的模块就不会部署到生产环境上。而branches上的稳定的版本就是发布到生产环境上的代码,如果用户 使用的过程中发现有bug,则只要在branches上修改该bug,修改完bug后再编译branches上最新的代码发布到生产环境即可。tags的 作用是将在branches上修改的bug的代码合并到trunk上时创建个版本标识,以后branches上修改的bug代码再合并到trunk上时就 从tags的version到branches最新的version合并到trunk,以保证前期修改的bug代码不会再合并。

    -------------------------------------------------------------------------------------------

    一直以来用svn只是当作cvs,也从来没有仔细看过文档,直到今天用到,才去翻看svn book文档,惭愧

    需求一:
    有一个客户想对产品做定制,但是我们并不想修改原有的svn中trunk的代码。

    方法:
    用svn建立一个新的branches,从这个branche做为一个新的起点来开发
    svn copy svn://server/trunk svn://server/branches/ep -m "init ep"

    Tip:

    如果你的svn中以前没有branches这个的目录,只有trunk这个,你可以用
    svn mkdir branches
    新建个目录

    需求二:

    产品开发已经基本完成,并且通过很严格的测试,这时候我们就想发布给客户使用,发布我们的1.0版本
    svn copy svn://server/trunk svn://server/tags/release-1.0 -m "1.0 released"

    咦,这个和branches有什么区别,好像啥区别也没有?
    是的,branches和tags是一样的,都是目录,只是我们不会对这个release-1.0的tag做修改了,不再提交了,如果提交那么就是branches

    需求三:
    有一天,突然在trunk下的core中发现一个致命的bug,那么所有的branches一定也一样了,该怎么办?
    svn -r 148:149 merge svn://server/trunk branches/ep

    其中148和149是两次修改的版本号。

  • svn 版本管理详解

    2010-05-10 10:27:55

    1. 导入一个未进行版本管理的本地项目到svn中
       命令:
            svn import [svn_path] [local folder]

       注意:
            本命令仅仅是将一个本地目录加入到svn responsitory 中。本地路径中的文件未进行管理,
            必须重新 svn checkout 一个本地拷贝进行操作。
            
    2. svn 常用命令

    2.1 更新命令

        svn update
        
    2.2 做出修改

        svn add
        svn delete
        svn copy
        svn move
        
    2.3 检验修改
        
        svn status
        svn diff
        
    2.4 取消修改
        
        svn revert
        
        一般在本地修改了文件,尚未提交修改之前,可以使用该命令,取消你所做的本地修改。
        
        或者:
        
        你在本地使用了 svn add/delete等修改操作, 但是尚未进行svn commint,也可以
        通过该命令取消之前的操作。
        
        例:
        你在本地创建了一个新的目录foo
        $svn status
        ? foo   //说明foo目录尚未加入到svn版本控制中
        
        $svn add foo
        $svn status
        A foo
        
        $svn revert
        $svn status
        ? foo
        
    2.5 解决冲突(合并别人的修改)
        
        svn update
        
        在进行svn update命令后,一般我们会看到每个更新文件的状态,具体状态字有如下几种:
        
        A: 表示添加
        D: 表示删除
        U: 表示更新
        G: 表示合并,并且合并过程中没有冲突
        C: 表示与本地文件发生冲突
        
        例:
        $svn update
        U intall
        G readme
        c bar.cpp
        update to revision 46.
        
        一旦发生冲突,svn会在你的更新目录下产生3个临时文件,等待你将冲突解决,
        冲突解决前不允许提交,即svn commit命令处理失败。
        
        例:
        $svn update
        C sandwich.txt
        update to revision 2;
        
        $ls -l
        sandwich.txt
        sandwich.txt.mine
        sandwich.txt.r1
        sandwich.txt.r2
        
        背景说明:
        张三和李四,同时在 revision 1的时候,checkout 到了本地;
        张三做为修改,并提交, 版本到 revision 2;
        李四此时未更新新版本,仍然在 revision 1 下修改sandwich.txt, 并且修改的地方与张三的修改冲突;
        李四修改后, 提交自己的修给, 发现提交失败, 报告版本太老;
        李四更新svn新版本,结果出现现在的冲突情况;
        
        sandwich.txt 
        sandwich.txt.mine  //! 当前李四修改的未提交的新版本本文件
        sandwich.txt.r1    //! 当前李四更新冲突前的svn版本文件
        sandwich.txt.r2    //! 当前李四更新冲突前的svn版本文件
        
        而sandwich.txt 则是冲突版本文件, 该文件中,svn系统会自动添加很多冲突标记
        
        <<<<<<<.mine //!冲突标记
        [李四修给内容]
        =======      //!冲突标记
        [张三修给内容]
        >>>>>>>.r2   //!冲突标记
        
        解决冲突的方法有3种:
        1. 手动修给冲突文件,将冲突标记删除
        2. 使用一个临时文件(.mine, .r1, .r2)覆盖当前版本
        3. 放弃本地修给 svn revert <filename>
        
        svn resolved
        
        一旦冲突解决,就可以使用 svn resolved命令 , 该命令会自动删除3个临时文件。
        
        例:
        $svn resolved
        Resolved conflicted state of "sandwich.txt".
        
        
    2.6 提交修改
        
        svn commit
        
        提交命令很简单,但是很多人在提交的时候,忘了写提交备注,或者备注写得不规范,给以后查询修给内容带来不便。
        
        备注例子:(使用序号说明每个修改)
        
        1. add xxx function
        2. fixed xxxx bug
        3. remove xxxx 
        

    3. svn 版本控制:分支、合并、标签
        
    3.1 规划版本库

       svn 目录:
        /
        |
        |——project_name
        |   |
        |   |-- trunk (主干)
        |   |
        |   |-- branches (分支)
        |   |
        |   |-- tags (标签)
        
        主干: 是整个项目开发的主线;
        分支: 可以是开发者自己独立出来的一个分支,
              也可以是一个新的项目,与主干项目有一些功能上的差异,需要单独分开出来;
        标签: 项目开发过程中,各阶段发布的版本快照;
        
        svn revision 编号说明:
        
            +(r4)     +(r7)    
            ----------------->braches/tom_branch   
            |  +r(5)        +r(10)                  +r(20)
        0--------------------------trunk---------------------->n
                    |
                    ----------------------------->branches/sally_brach
                    +(r6)            |(r12)
        
        ----------按时间递增---------------------------------------->
        
        
        svn merge
        
        svn merge 是个比较复杂的命令,下面做一个简单例子说明:
        背景:
        tom在自己的分支下走到了revision 7状态,
        此时主干开发,发现了一个bug, 该bug在tom的分支下也存在,
        主干开发修复该bug,主干版本到revision 10
        
        此时,tom决定将主干中该bug的修复,提交到自己的分支中:

        $svn merge -r 5:10 <svn目录>/trunk  <svn目录>>/branches/tom_branch
        U aa.c
        C bb.c
        发现此时 bb.c 文件在tom的分支下出现冲突,于是我们参照冲突的处理办法,解决冲突。
        
        $svn commit 
        提交此次合并的操作。
        
        
        svn copy 
         
        该命令主要于用户开新的分支与打标签。
        
        例子:
        
        tom从当前的trunk版本下,开一个独立的分支
        
        $svn copy <svn目录>/trunk <svn目录>>/branches/tom_branch
        $svn commit 
        
        tom将自己的开发分支,发布一个新的版本,此时就打一个标签

        $svn copy <svn目录>>/branches/tom_branch <svn目录>/tags/project_tom.1.0.0
        $svn commit 
        
        
        svn export
        发布项目时,不能将一些.svn信息也发布到安装包中,此时就需用 svn export命令
        例子:
        $svn export <svn目录>/tags/project_tom.1.0.0  ./project_tom.release.1.0.0 
        $tar -cvzf project_tom.release.1.0.0.tar.gz  ./project_tom.release.1.0.0 

TAG: svn SVN

 

评分:0

我来说两句

Open Toolbar