SVN使用技巧

程序员编写程序的过程中,每个程序都会有很多不同的版本,这就需要程序员很好的管理代码,在需要的时间可以取出需要的版本,并且每个版本都有一个完整的说明。
我们使用Sub Version(简称SVN)作为版本管理工具。这里着重介绍SVN作为跨平台的多人协作使用方法。在多个程序员管理同一段代码的过程中,版本的管理显得尤为重要,使用SVN可以方便的进行分支、合并,记录下所有的版本。
基本配置
在开始某项软件、文档的开发与撰写时,首先由配置管理负责人建立SVN仓库、用户名及其权限,并通知相关人员SVN仓库地址、SVN仓库负责人。
SVN仓库的负责人把工程的tsvn:logminisize设置为1,以便强制注释。设置方法:在你的工程文件夹右键->属性中,进入Subversion标签,选中tsvn: logminisize,确保复选框recursive选中,然后点击Set按钮把它的值设为1,其意思是指提交的注释最短长度为一个字。如图:
图 2 . 1
软件配置
l        忽略文件
在 SVN 的 [Setting] 的 [General] 中 , 设置需要忽略的文件以便忽略掉一些临时的、无用的文件 , 常被忽略的文件有 *.opt *.ncb *.suo *.plg *.pch *.idb *.pdb *.scc *.obj Debug Release *.o *.bin *.out *.ilk *.aps debug release *.clw *.bak 。每个程序员可以根据自己的需要进行修改忽略文件,上面只是使用VC++与Tornado编程时常用的一些忽略文件。
图 2 . 2
以上说的忽略文件是指全局的忽略文件。SVN还能在特定的目录中指定需要忽略的文件。忽略文件支持通配符。
l        合并比较工具
在Merge Tool中可以选择用来合并的工具,强烈推荐用Araxis Merge。在[Setting]->[Diff]中填入"C:/Program Files/Araxis/Araxis Merge v6.5/Merge.exe";在[Setting]->[Merge]的选项中,填入"C:/Program Files/Araxis/Araxis Merge v6.5/Merge.exe" %theirs %mine %merged ;其中"C:/Program Files/Araxis/Araxis Merge v6.5/Merge.exe"是指合并工具的路径,%theirs %mine %merged分别指..将要合并到主干的分支,主干,及合并后的结果。
图 2 . 3
仓库目录结构
SVN仓库的负责人规划好仓库的目录结构。推荐的目录结构如下图所示。
仓库的一级目录只有两个,分别为code和doc。其中,doc主要用来放置先期的文档,code主要用来放置工程的代码,也可以包含后期的文档。
仓库的二级目录只可以是branch与trunk两个目录,分别存放主干与分支。trunk目录下直接存放工程文件。branch目录下包括一些子目录分别对应各个分支。
图 2 . 4
从 SVN 仓库中取出代码时 ,一定 不要把整个仓库取出来 , 而应该只取出 trunk 目录 , 或只取出 branch 下的某个分支目录 (比 如上图中的 svn://code/branch/xw_051206 ) 。
一个项目会有多个人共同合作开发完成。基本流程是:
l        各开发成员建立自己的分支,并在此分支上开发;
l        各开发成员把分支合并到主干上并形成较为稳定的版本;
l        各个成员重新从主干上建立新的分支,在此分支上开发 ( 即回到第一步 )
l        循环往复,直到工程结束。
下面我用一个例子来说明合作开发的基本流程。
现在xb与lzj两个开发人员要共同开发一个工程onlytest,其这个工程的主干的SVN仓库地址如下图。
图 2 . 5
xb与lzj分别在onlytest这个工程中建立两个分支,分别为xb _051115和lz_051115。
在这里分支命名要采用[姓名缩写_6个数的日期_后缀(可选)]的形式,比如xb_051208_1,xb_051212之类的。创建完分支后我们可以看到这个工程的目录结构如下图所示:
图 2 . 6 分支目录
建完之后, xb和lzj分别在本地取出对应的分支进行开发。
当 程序到达一个比较稳定的阶段,就需要把分支合并到主干上,下面讲述一下合并的流程。
在本节中继续使用上一节中所示的工程与SVN仓库讲解。
1.2.3.1 xb 与 lzj 分别修改自己分支上的代码
现在 , 主干上的 test_SVN.txt 是空文档。
由 xb 与 lzj 修改提交后 , 两个分支中 test_SVN.txt 分别如下两图所示 :
图 2 . 7 xb_051129 分支下的 test_SVN.txt
图 2 . 8 lzj_051129 分支下的 test_SVN.txt
1.2.3.2 xb 将 xb_051129 分支合并到主干
xb 先把主干 check out 到本地。然后在主干的目录上右键 选择svn->merge,弹出如下窗口:
图 2 . 9 合并对话框
此对话框的含义是把From指定的分支版本到To指定的分支版本之间的差异合并到主干上。
在这里分支选的是xb_051129。版本号的选定方法是点击From中的Show Log,在Log窗口中按住Ctrl键,点击选择”made a copy”之上的那个版本,以及最顶上的那个版本,如图2.11所示。然后点击确定回到上图中的对话框,会自动填写From与To中的Revision号。
2 . 10 选择需要合并的版本
然后直接点击merge进行合并,你也可以通过dry run来看是不是两者之间有差异。由于没有其它人修改主干,所以合并的很顺利,下图是xb_051115与主干合并后的结果。合并完毕之后,由xb对主干进行提交。
图 2 . 11 合并后,主干上的 test_SVN.txt
 
1.2.3.3 lzj 将 lzj_051129 分支合并到主干,解决冲突
xb合并完毕之后,lzj要将他的分支合并到主干上去,方法同上。但是由于xb已经修改过主干,所以产生了冲突,会弹出一个冲突对话框。双击对话框中的产生冲突的文件名,就可以调出工具对此文件进行合并,下图是我们用merge工具显示的界面。
图 2 . 12
l        首先比较第一个窗口与第二个窗口,把结果修改合并到第二个窗口。
l        然后确保光标处于第二个窗口时,点击上图中红色圈圈所示的按钮。这样会把第二个窗口的内容全部复制到第三个容口。之后保存,退出。
l        然后在工程目录上点右键,进行SVN->Resolved。这样会删除无用的临时文件。
l        最后提交所作的修改,并添加详细的注释。
中的标签
与CVS不同,使用SVN时不用专门为目录添加标签,因为SVN也对目录进行版本管理。
我们在提交时写好注释(比如重要的版本提交时使用 051201 之类的日期作为开头),就可以通过注释来查找比较重要的目录版本号,相当于 CVS 或 VSS 中的标签。
另外,每个工程都会有一个版本说明文件,通过此文件可以查找关键版本。
你可以重命名、移动或删除你的文件或文件夹,但请使用SVN进行这些操作,否则之前的版本信息会丢失。
使用SVN删除、移动与重命名文件夹的方法是在文件/文件夹上点右键进行SVN操作,或直接在资源浏览器中使用右键拖放(会弹出SVN选项)。
文件的删除、移动与重命名之前,必须保证工作目录是最新的版本;进行这些操作之后,需要进行提交。
1.3.3 版本的回退
在代码的编写过程中,难免会有不尽人意的地方,你也许需要回退到某一个版本,但是在这个过程中可能有一些文件你想保留,也有一些文件你不想保留,这就牵扯到很复杂的版本管理过程,在这里给大家推荐几种方法。
1.        若是你编辑了工程,在没有提交的前提下,你想放弃这些修改,你可以直接选择 revert 就可以更新到工程的最新的版本。
2.        若是你想退回到某一个版本,你就可以直接选择 update to reversion 如图 , 这样我们就可以把我们的版本回退到你选中的版本去,这种情况下 SVN 并没有显示出有什么冲突,并且新建立的文件也还在,但是在这种情况下你并不能直接在你回退后的版本上进行编辑,因为 SVN 的版本控制还是在最新的主干上。我们需要 update 并解决冲突。
3.        你可以直接选择 revert changes from this revision 如图,这样的话你可以直接解决冲突并提交。不过这种方法的不足是,你新建的文件都没有了,整个工程都回退到之前的版本了。
4.        我推荐的一种方法是,直接 export 一个你需要的版本,然后用你 export 的版本覆盖你的最新的版本,这样你就可以不丢失你新建的文件,同时获得 head 的 SVN 控制文件。
图 13
 
每个工程会有很多个小模块,当某个模块达到稳定的时候,你就需要提交一次,以免写下个模块代码的时候出现不可恢复的错误。
每一次提交需要前,需要通过pclint检查,保证是一个编译没有错误的版本。当提交比较稳定的版本的时候,同时要修改你的版本号。
1.3.5 版本说明文件
版本说明文件为xml表格,可用excel编辑,它会记录下关键的版本信息。
版本说明文件内容如下表。发布版本是指用户对外公布的版本号,后文中有详细描述;Revision是SVN内部的工程文件夹的版本号。一个发布版本可能对应多个Revision:
发布版本
Revision
详细说明
1,0,0,12
76
加入了抗干扰日志,需长时间测试
程序代码进行了重构,已经调试通过
77
xxx @#$%^&
78
啥...
1,0,0,13
81
测试过的稳定版本
1,0,0,14
99
fix some bug,没有测试
 
 
 
 
附件 大小
svn版本管理教程.rar 474.51 KB
 
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
早在2000年,CollabNet, Inc.就开始召集开发人员开发CVS的替代品。CollabNet 提供一套名为SourceCast协同工作套件,其中的一部分组件是版本控制。虽然SourceCast使用CVS作为其最初的版本控制系统,但是CVS的种种限制从一开始就处处可见,最后CollabNet明白必须要找到一个更好的解决方案。不幸的是,至少在免费license中,因为没有更好的选择,CVS已经广泛成为了开源世界中事实上的标准。所以CollabNet决定开发一个新的版本控制系统,保留CVS的基本特性但去除CVS的bug和不好的特性。   在2000年2月,他们联系《使用CVS开发开源项目》(Open Source Development with CVS)(Coriolis, 1999)的作者Karl Fogel,并征求了他是否愿意在这个新的项目中担任一个角色。巧合的是,当时Karl已经和他的朋友Jim Blandy讨论了一个关于新的版本控制系统的设计。在1995年,这两人就成立了Cyclic Software,一个提供CVS的商业支持的软件公司。虽然他们经营商业服务,但是仍然在每天都在工作中使用CVS。使用CVS的挫折感使得Jim认真思考更好的方法来管理数据,不但确定名字为“Subversion”,而且完成了Subversion档案库的基础设计。   当CollabNet的电话到来时,Karl立即答应了加入项目中,而且Jim让他的雇主RedHat Software同意让他在这个项目中不定期工作。CollabNet雇用了Karl和Ben Collins-Sussman,并在5月开始了详细设计工作。在得到了来自CollabNet的Brian Behlendorf、Jason Robbins和Greg Stein(当时是一名活跃在WebDAV/DeltaV规范过程的自由程序员)很多创意的帮助下,Subversion很快地引起了一个活跃开发者社区的注意。它找出并欢迎很多同样在CVS上受到挫折的社员能来为这个项目做点什么。   Subversion 最初的设计Team定下了几个简单的目标。 它必须在功能上可取代 CVS,也就是说, 所有 CVS 可做到的事, 它都要能够作到。 在修正最明显的瑕疵的同时, 还要保留相同的开发模式。 还有, Subversion 应该要和 CVS 很相像, 任何 CVS 使用者只要花费少许的力气, 就可以很快地上手。   经过十四个月的编码后, Subversion 于2001年8月31日开始实现 “自行管理”。 也就是说, 开发人员不再使用 CVS 来管理 Subversion 的代码, 而以 Subversion 自己来管理。   从启动这个项目到现在,虽然CollabNet提供了大部分的资金(它付出几位全职 Subversion 开发人员的薪水), 但这还是个开源项目, 由一组松散透明的规则所约定。 CollabNet 拥有代码的版权完全符合 Debian Free Software Guidelines。 换句话说, 每个人都可以随意地免费下载、修改、以及重新发布 Subversion; 完全不需要经过 CollabNet, 或是任何人的允许。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值