mac SVN

目录结构

• SVN有一个很标准的目录结构，是这样的。比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是

   svn://proj/
   |
   +-trunk    (主开发目录)
   +-branches (分支开发目录)
   +-tags     (tag存档目录-不允许修改)

• 这是一个标准的布局。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。

• 对于这几个开发目录，一般的使用方法有两种。

  第一种方法，使用trunk作为主要的开发目录:

  • 一般的，我们的所有的开 发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码 处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk 进行开发。此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。例 如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。

1.0开发完毕，代码冻结基于已经冻结的trunk，为release1.0打tag
此时的目录结构为
svn://proj/
+trunk/ (freeze)
+branches/
+tags/
    +tag_release_1.0　(copy from trunk)

2.0 开始开发，trunk此时为2.0的开发版
发现1.0有bug，需要修改，基于1.0的tag做branch
此时的目录结构 为
svn://proj/
+trunk/ ( dev 2.0 )
+branches/
     +dev_1.0_bugfix (copy from tag/release_1.0)
+tags/
     +release_1.0　(copy from trunk)
在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发
在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等
根据需要选择性的把 dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）

• 这是一种很标准的开发模 式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

第二种方法，在每一个release的branch中进行各自的开发

trunk只做发布使用。这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经 release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。

1.0开发，做 dev1.0的branch
此时的目录结构
svn://proj/
+trunk/ (不担负开发任务 )
+branches/
    +dev_1.0 (copy from trunk)
+tags/

1.0开发完成，merge dev1.0到trunk
此时的目 录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
     +dev_1.0 (开发任务结束，freeze)
+tags/

根据trunk做1.0的tag
此时的目录结构
svn://proj/
+trunk/ (merge from branch dev_1.0)
+branches/
    +dev_1.0 (开发任务结束，freeze)
+tags/
    +tag_release_1.0 (copy from trunk)

1.0开发，做dev2.0分支
此时的目录结构
svn://proj/
+trunk/ 
+branches/
    +dev_1.0 (开发任务结束，freeze)
    +dev_2.0 （进行2.0开发）
+tags/
    +tag_release_1.0 (copy from trunk)

1.0有bug，直接在dev1.0的分支上修复
此时的目录结构
svn://proj/
+trunk/ 
+branches/
    +dev_1.0 (1.0bugfix)
    +dev_2.0 （进行2.0开发）
+tags/
    +tag_release_1.0 (copy from trunk)
选择性的进行代码merge

• 这其实是一种分散式的开发，当各个部分相对 独立一些（功能性的），可以开多个dev的分支进行开发，这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache 等。但是这样merge起来就是一个很痛苦的事情。
  这里要注意一下的，第六步进行选择性的merge，是可以当2.0开发结束后一起把 dev_1.0（bugfix用）和dev_2.0（新版本开发 用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行测试等之后再merge回trunk。
  这两种方法各有利弊，第一种方法是可以得到一个比较纯的dev_2.0的 开发分支，而第二种方法则更加的保险，因为要测试嘛。
  以上呢，就是我说的两种开发模式了，具体哪种好，并没有定论。这里大致的说一下各自的优缺点：

      第一种开发模式（trunk进行主要开发，集中式）：
          优点：管理简单
          缺点：当开发的模块比较多，开发人数/小团队比较多 的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动
      第二重开发模式（分支进行主要开发，分散式）：
          优点：各 自开发独立，不容易相互影响。
          缺点：管理复杂，merge的时候很麻烦。

• 其实，这里并没有一定之规，更多的时候是两种 模式结合使用。

常用命令

#下载到本地
svn checkout path(path是服务器的目录) 

#往版本库中添加新的文件
svn add filename                    

#将改动的文件提交到版本库
svn commit -m "注释" filePath
简写：svn ci                           

#加锁/解锁
svn lock -m "注释" path
svn unlock path

#更新到某个版本
svn update -r 版本号 path          
svn update 更新当前目录以及子目录下的所有文件到最新版本
svn upate -r 200 test.cpp 将版本库中的test.cpp还原到版本200
简写 svn up

#查看文件或者目录状态
svn status path （显示目录下的文件和子目录下的文件状态,正常状态不显示）
【?:不在svn控制中;M:内容被修改;C：发生冲突;A:预定义加入到版本库;K:被锁定】
svn status -v path （显示文件和子目录状态）
简写： svn st

#删除文件
svn delete path -m "注释"
简写： svn (del、remove、rm)

#查看日志
svn log path

#查看文件详细信息
svn info path

#比较差异
svn diff path（将修改的文件与基础版本比较）
svn diff -r m:n （将修改的文件m版本和n版本比较）
简写 svn di

#将两个版本的文件的差异合并到当前文件
svn merge -r m:n path
例如：svn merge -r 20:25 test.cpp（将版本20与25之间的差异合并到当前文件，但一般会发生冲突，需要处理一下）

#SVN帮助
svn help

#查看版本库下的文件和列表
svn list path （显示path目录下的所属于版本的文件和目录）
简写: svn ls

#创建纳入版本控制下的新目录
svn mkdir: 创建纳入版本控制下的新目录。
用法: 1、mkdir PATH...
      2、mkdir URL...
创建版本控制的目录。
1、每一个以工作副本 PATH 指定的目录，都会创建在本地端，并且加入新增调度，以待下一次的提交。
2、每个以URL指定的目录，都会透过立即提交于仓库中创建。在这两个情况下，所有的中间目录都必须事先存在。

#恢复本地修改
svn revert：恢复原始未改变的工作副本文件（恢复大部分的本地修改）revert用法：revert path
注意：本子命令不会存储网络，并且会解除冲突的情况。但它不会恢复被创建的目录

#代码库URL变更
svn switch(sw): 更新工作副本到不同的URL。
用法 1、switch URL [PATH]
    2、switch --relocate FROM TO [PATH]
1、更新工作副本，映射到一个新的URL，会将服务上的文件与本地文件合并。这是将工作副本对应到同一创库的某个分支或者标记的方法。
2、改写工作副本URL元数据，以反映URL的变更，创库URL变动但工作副本仍旧对映同一创库的同一目录时使用该命令更新工作副本与创库的对应关系。

#解决冲突
svn resolved：移除工作副本的目录或文件的“冲突”状态。
用法 resolved path
注意：本子命令不会依语法来解决冲突或是移除冲突标记；它只是移除冲突的相关文件，然后让path可以再次提交。

#输出指定文件的URL内容
svn cat 目标[@版本] 如果指定了版本将从指定的版本开始查找。

注意：svn status、svn diff和svn revert这三条命令在没有网络情况下可以执行，因为svn在本地.svn中保留了本地版本原始拷贝。

参考

https://blog.csdn.net/liuchong_lch/article/details/78192755
https://www.cnblogs.com/newstar/archive/2011/01/04/svn.html