[Linux & SVN] SVN介绍及Linux下SVN命令收录

1. SVN是什么?  

  SVN是Subversion的简称,是一个开放源代码的版本控制系统,相较于RCS、CVS,它采用了分支管理系统,它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。

  集中式管理的工作流程如下图:

 

  集中式代码管理的核心是服务器,所有开发者在开始新一天的工作之前必须从服务器获取代码,然后开发,最后解决冲突,提交。所有的版本信息都放在服务器上。如果脱离了服务器,开发者基本上可以说是无法工作的。下面举例说明:
  开始新一天的工作:
  1、从服务器下载项目组最新代码。
  2、进入自己的分支,进行工作,每隔一个小时向服务器自己的分支提交一次代码(很多人都有这个习惯。因为有时候自己对代码改来改去,最后又想还原到前一个小时的版本,或者看看前一个小时自己修改了哪些代码,就需要这样做了)。
  3、下班时间快到了,把自己的分支合并到服务器主分支上,一天的工作完成,并反映给服务器。
  这就是经典的svn工作流程,从流程上看,有不少缺点,但也有优点。

2. SVN的三部分

  SVN的工作机制在某种程度上就像一颗正在生长的树:

  • 一颗有树干和许多分支的树
  • 分支从树干生长出来,并且细的分支从相对较粗的树干中长出
  • 一棵树可以只有树干没有分支(但是这种情况不会持续很久,随着树的成长,肯定会有分支啦,
  • 一颗没有树干但是有很多分支的树看起来更像是地板上的一捆树枝
  • 如果树干患病了,最终分支也会受到影响,然后整棵树就会死亡
  • 如果分支患病了,你可以剪掉它,然后其他分支还会生长出来的哦!
  • 如果分支生长太快了,对于树干它可能会非常沉重,最后整棵树会垮塌掉
  • 当你感觉你的树、树干或者是分支看起来很漂亮的时候,你可以给它照张相,这样就就可以记得它在那时是多么的赞。

  关于SVN有一个很形象的图来展示,如下:

2.1 Trunk

  Trunk是放置稳定代码的主要环境,就好像一个汽车工厂,负责将成品的汽车零件组装在一起。

  以下内容将告诉你如何使用SVN trunk:

  • 除非你必须处理一些容易且能迅速解决的BUG,或者你必须添加一些无关逻辑的文件(比如媒体文件:图像,视频,CSS等等),否则永远 不要在trunk直接做开发
  • 不要因为特殊的需求而去对先前的版本做太大的改变,如何相关的情况都意味着需要建立一个branch(如下所述)
  • 不要提交一些可能破坏trunk的内容,例如从branch合并
  • 如果你在某些时候偶然间破坏了trunk,bring some cake the next day (”with great responsibilities come… huge cakes”)

2.2 Branches

  在SVN中主干代码一般是放置在Trunk目录下的,如果要新建Branch的话则放置在Branchs目录下。(注意这是一种约定,SVN并不强制你这样做)注意Branhs和Trunk目录要平级,不能有嵌套,要不会引起混乱。  

myproject/
      trunk/
      branches/
      tags/

  一个branch就是从一个SVN仓库中的子树所作的一份普通拷贝。通常情况它的工作类似与UNIX系统上的符号链接,但是你一旦在一个SVN branch里修改了一些文件,并且这些被修改的文件从拷贝过来的源文件独立发展,就不能这么认为了。当一个branch完成了,并且认为它足够稳定的时 候,它必须合并回它原来的拷贝的地方,也就是说:如果原来是从trunk中拷贝的,就应该回到trunk去,或者合并回它原来拷贝的父级branch。

  以下内容将告诉你如何使用SVN branches:

  • 如果你需要修改你的应用程序,或者为它开发一个新的特性,请从trunk中创建一个新的branch,然后基于这个新的分支进行开发
  • 除非是因为必须从一个branch中创建一个新的子branch,否则新的branch必须从trunk创建
  • 当你创建了一个新branch,你应当立即切换过去。如果你没有这么做,那你为什么要在最初的地方创建这个分支呢?

  创建:创建一个Branch也相当简单,只需要一条命令即可:

svn copy http://example.com/repos/myproject/trunk http://example.com/repos/myproject/branches/releaseForAug -m 'create branch for release on August'

  合并:既然要创建分支也需要合并分支。基本的合并也是蛮简单的。

  假设现在Branch上fix了一系列的bug,现在我们想把针对Branch的改变同步到Trunk上,那么应该怎么做那?

  1. 保证当前Branch分支是clean的,也就是说使用svn status看不到任何的本地修改。

  2. 命令行下切换到Trunk目录中,使用 svn merge http://example.com/repos/myproject/branches/releaseForAug 来将Branch分支上的改动merge回Trunk下。

  3. 如果出现merge冲突则进行解决,然后执行svn ci -'description'来提交变动。

  当然在merge你也可以指定Branch上那些版本变更可以合并到Trunk中。

  svn merge  http://example.com/repos/myproject/branches/releaseForAug -r150:HEAD

  示例中是将Branch的从版本150到当前版本的所有改动都合并到Trunk中。

  你也可以将Trunk中的某些更新合并到Branch中,还是同样的方法。

  查看当前Branch和Trunk的合并情况

  可以使用svn mergeinfo来查看merge情况。

  查看当前Branch中已经有那些改动已经被合并到Trunk中:

# cd to trunk directory
svn mergeinfo http://example.com/repos/myproject/branches/releaseForAug

  查看Branch中那些改动还未合并。

#cd to trunk directory

svn merginfo http://example.com/repos/myproject/branches/releaseForAug --show-revs eligible

2.3 Tags

  从表面上看,SVN branches和SVN tags没有什么差别,但是从概念上来说,它们有许多差别。其实一个SVN tags就是上文所述的“为这棵树照张相”:一个trunk或者一个branch修订版的命名快照。

  以下内容将告诉你如何使用SVN tags:

  • 作为一个开发者,永远不要切换至、取出,或者向一个SVN tag提交任何内容:一个tag好比某种“照片”,并不是实实在在的东西,tags只可读,不可写。
  • 在特殊或者需要特别注意的环境中,如:生产环境(production)、?(staging)、测试环境(testing)等等,只 能从一个修复过的(fixed)tag中checkout和update,永远不要commit至一个tag。
  • 对于上述提及到的环境,可以创建如下的tags:“production”,“staging”,“testing”等等。你也可以根 据软件版本、项目的成熟程度来命名tag:“1.0.3”,“stable”,“latest”等等。
  • 当trunk已经稳定,并且可以对外发布,也要相应地重新创建tags,然后再更新相关的环境(production, staging, etc)

  工作流样例:

  假设你必须添加了一个特性至一个项目,且这个项目是受版本控制的,你差不多需要完成如下几个步骤:

  1. 使用SVN checkout或者SVN switch从这个项目的trunk获得一个新的工作拷贝(branch)
  2. 使用SVN切换至新的branch
  3. 完成新特性的开发(当然,要做足够的测试,包括在开始编码前)
  4. 一旦这个特性完成并且稳定(已提交),并经过你的同事们确认,切换至trunk
  5. 合并你的分支至你的工作拷贝(trunk),并且解决一系列的冲突
  6. 重新检查合并后的代码
  7. 如果可能的话,麻烦你的同事对你所编写、更改的代码进行一次复查(review)
  8. 提交合并后的工作拷贝至trunk
  9. 如果某些部署需要特殊的环境(生成环境等等),请更新相关的tag至你刚刚提交到trunk的修订版本
  10. 使用SVN update部署至相关环境

3. 常用的SVN命令

  1、将文件checkout到本地目录 
  svn checkout path(path是服务器上的目录) 
  例如:svn checkout svn://192.168.1.1/pro/domain 
  简写:svn co 
  2、往版本库中添加新的文件 
  svn add file 
  例如:svn add test.php(添加test.php) 
  svn add *.php(添加当前目录下所有的php文件) 
  3、将改动的文件提交到版本库 
  svn commit -m “LogMessage“ [-N] [--no-unlock] PATH(如果选择了保持锁,就使用–no-unlock开关) 
  例如:svn commit -m “add test file for my test“ test.php 
  简写:svn ci 

  note: 在提交(ci)之前一定要先进行版本的更新,否则会覆盖上一个提交(很可能在你开发过程中,你的同事已经进行了版本的更新)的版本!!!

  ci的具体流程:

  (1)进入修改的目录下,查看修改的信息:

    svn diff

    svn info

  (2)将版本更新到最新版本:

    svn up

  (3)提交修改后的版本:

    svn ci -m "comment"

  4、加锁/解锁 
  svn lock -m “LockMessage“ [--force] PATH 
  例如:svn lock -m “lock test file“ test.php 
  svn unlock PATH 
  5、更新到某个版本 
  svn update -r m path 
  例如: 
  svn update如果后面没有目录,默认将当前目录以及子目录下的所有文件都更新到最新版本。 
  svn update -r 200 test.php(将版本库中的文件test.php还原到版本200) 
  svn update test.php(更新,于版本库同步。如果在提交的时候提示过期的话,是因为冲突,需要先update,修改文件,然后清除svn resolved,最后再提交commit) 
  简写:svn up 
  6、查看文件或者目录状态 
  1)svn status path(目录下的文件和子目录的状态,正常状态不显示) 
  [?:不在svn的控制中;M:内容被修改;C:发生冲突;A:预定加入到版本库;K:被锁定]
  2)svn status -v path(显示文件和子目录状态) 
  第一列保持相同,第二列显示工作版本号,第三和第四列显示最后一次修改的版本号和修改人。 
  注:svn status、svn diff和 svn revert这三条命令在没有网络的情况下也可以执行的,原因是svn在本地的.svn中保留了本地版本的原始拷贝。 
  简写:svn st 
  7、删除文件 
  svn delete path -m “delete test fle“ 
  例如:svn delete svn://192.168.1.1/pro/domain/test.php -m “delete test file” 
  或者直接svn delete test.php 然后再svn ci -m ‘delete test file‘,推荐使用这种 
  简写:svn (del, remove, rm) 
  8、查看日志 
  svn log path 
  例如:svn log test.php 显示这个文件的所有修改记录,及其版本号的变化 
  9、查看文件详细信息 
  svn info path 
  例如:svn info test.php 
  10、比较差异 
  svn diff path(将修改的文件与基础版本比较) 
  例如:svn diff test.php 
  svn diff -r m:n path(对版本m和版本n比较差异) 
  例如:svn diff -r 200:201 test.php 
  简写:svn di 
  11、将两个版本之间的差异合并到当前文件 
  svn merge -r m:n path 
  例如:svn merge -r 200:205 test.php(将版本200与205之间的差异合并到当前文件,但是一般都会产生冲突,需要处理一下) 
  12、SVN 帮助 
  svn help 
  svn help ci 
  —————————————————————————— 
  以上是常用命令,下面写几个不经常用的 
  —————————————————————————— 
  13、版本库下的文件和目录列表 
  svn list path 
  显示path目录下的所有属于版本库的文件和目录 
  简写:svn ls 
  14、创建纳入版本控制下的新目录 
  svn mkdir: 创建纳入版本控制下的新目录。 
  用法: 1、mkdir PATH… 
  2、mkdir URL… 
  创建版本控制的目录。 
  1、每一个以工作副本 PATH 指定的目录,都会创建在本地端,并且加入新增 
  调度,以待下一次的提交。 
  2、每个以URL指定的目录,都会透过立即提交于仓库中创建。 
  在这两个情况下,所有的中间目录都必须事先存在。 
  15、恢复本地修改 
  svn revert: 恢复原始未改变的工作副本文件 (恢复大部份的本地修改)。revert: 

  用法: revert PATH… 
  注意: 本子命令不会存取网络,并且会解除冲突的状况。但是它不会恢复被删除的目录。 
  16、代码库URL变更 
  svn switch (sw): 更新工作副本至不同的URL。   
  用法: 1、switch URL [PATH] 
  2、switch –relocate FROM TO [PATH...] 
  1、更新你的工作副本,映射到一个新的URL,其行为跟“svn update”很像,也会将服务器上文件与本地文件合并。这是将工作副本对应到同一仓库中某个分支或者标记的方法。 
  2、改写工作副本的URL元数据,以反映单纯的URL上的改变。当仓库的根URL变动(比如方案名或是主机名称变动),但是工作副本仍旧对映到同一仓库的同一目录时使用这个命令更新工作副本与仓库的对应关系。 
  17、解决冲突 
  svn resolved: 移除工作副本的目录或文件的“冲突”状态。 
  用法: resolved PATH… 
  注意: 本子命令不会依语法来解决冲突或是移除冲突标记;它只是移除冲突的相关文件,然后让 PATH 可以再次提交。 
  18、输出指定文件或URL的内容。 
  svn cat 目标[@版本]…如果指定了版本,将从指定的版本开始查找。 
  svn cat -r PREV filename > filename (PREV 是上一版本,也可以写具体版本号,这样输出结果是可以提交的)

posted @ 2015-07-24 08:32  Poll的笔记  阅读(6370)  评论(0编辑  收藏  举报