SVN中trunk,branches,tags用法详解
SVN命令操作手册
SVN导出（export）
• export的目录不带TSVN的绿色标记，也没有.svn目录， 是一份干净的目录。相当于复制了一份服务器中的资料， 导出的文件不受版本控制。
• • • •
svn svn svn svn ）
export export export export
svn://192.168.230.140/test - -username test1(账号） -r10 svn://192.168.230.140/test - -username test1(账号） svn://192.168.230.140/test@10 - -username test1(账号） test(受版本控制的本地工作副本） work（导出副本存放的路径
SVN解决冲突（resolve）
• 产生冲突主要有两种情况，一种是分支合并时产生，一种是多个用户 对同一个文件进行了修改提交时产生。
SVN切换（SwitБайду номын сангаасh）
注意：切换后的目录要进行svn up更新，这个工作副本以下 的目录及文件不能进行递归切换。
SVN属性(Properties)
• svn proplist (plist, pl)
SVN合并（Merge）
• 合并方法： 1、用svn log -v查看分支基于主干的哪个修订号创建，记下主干基准修订号和分支最初创 建的修订号。 2、用svn diff 检查自创建起到现在的最新版本有哪些文件有修改。 eg:svn diff -r10：20 |grep Index（假设10是分支最初创建的修订号，20是要合并的版 本） 3、用svn diff 检查自从拉分支到现在最新的版本是否有修改。 eg:svn diff -r9：HEAD |grep Index （假设9是分支创建时基于主干基准修订号， HEAD为主干最新版本） 4、再比较下分支和主干两边的差异，如果有差异的文件要逐一排查。否则在用merge合并 时会有冲突产生。 eg：diff -qr branch trunk 5、如果是分支多余主干的要用svn cp 过去。如果是主干多余的要询问详情，谨慎删除 6、将会产生冲突的文件处理完成后这时可以用svn merge以目录树的形式合并。 eg: svn merge branch@10 branch@HEAD trunk(将分支的最新版本与最初版本之 间的修改合并到主干的最新版本） 7、确定合并没问题后再进行提交。
SVN 查看历史信息命令及用法
SVN 查看历史信息通过svn命令可以根据时间或修订号去查看过去的版本，或者某一版本所做的具体的修改。
以下四个命令可以用来查看svn 的历史：svn log 用来展示svn 的版本作者、日期、路径等等；svn diff 用来显示特定修改的行级详细信息；svn cat 取得在特定版本的某文件显示在当前屏幕；svn list 显示一个目录或某一版本存在。
（一）svn loglog: 显示一组版本与/或文件的提交日志信息。
用法: 1、log [PA TH]2、log URL[@REV] [PA TH...]1、显示本地PA TH (默认: “.”) 的日志信息。
默认的版本范围是BASE:1。
2、显示URL 中PA TH (默认: “.”) 的日志信息。
如果指定了REV，就从REV开始查找URL，版本范围是REV:1。
否则就从HEAD 开始查找URL，版本范围是HEAD:1。
可以指定多个“-c”或“-r”选项(但是不允许同时使用“-c”和“-r”选项)，以及混合使用前向和后向范围。
使用-v 时，在日志信息中显示受影响的路径名。
使用-q 时，不显示日志信息主体(请注意，它可与-v 并存)。
每条日志信息只会显示一次，即使指定了此版本涉及到的多个路径。
默认日志信息会追溯复制历史；使用--stop-on-copy 可以关闭这种行为，这可以用来找出分支点。
有效选项:-r [--revision] ARG : ARG (一些命令也接受ARG1:ARG2范围)版本参数可以是如下之一:NUMBER 版本号'{' DA TE '}' 在指定时间以后的版本'HEAD' 版本库中的最新版本'BASE' 工作副本的基线版本'COMMITTED' 最后提交或基线之前'PREV' COMMITTED的前一版本-q [--quiet] : 不打印信息，或只打印概要信息-v [--verbose] : 打印附加信息-g [--use-merge-history] : 从合并历史使用/显示额外信息-c [--change] ARG : 版本ARG 引起的改变--targets ARG : 传递文件ARG 内容为附件参数--stop-on-copy : 查看历史不要跨越不同的副本--incremental : 给予适合串联的输出--xml : 输出为XML-l [--limit] ARG : 日值项最大值--with-all-revprops : 获取所有版本属性--with-no-revprops : 没有找回版本属性--with-revprop ARG : 获取版本属性ARG全局选项:--username ARG : 指定用户名称ARG--password ARG : 指定密码ARG--no-auth-cache : 不要缓存用户认证令牌--non-interactive : 不要交互提示--trust-server-cert : 不提示的接受未知的SSL 服务器证书(只用于选项“--non-interactive”)--config-dir ARG : 从目录ARG 读取用户配置文件--config-option ARG : 以下属格式设置用户配置选项：FILE:SECTION:OPTION=[V ALUE]例如：servers:global:http-library=serf实例1：获取版本号14的版本信息svn log -r r14 或者svn log -r 14实例2：获取版本号14至17的版本信息svn log -r r14:r17 或者svn log -r 14:17实例3：获取全部版本信息svn log实例4：获取制定单个文件的版本信息svn log foo.csvn log /repo/project/foo.csvn log /repo/project foo.c bar.c实例5：查看版本信息及提交的文件路径并导入以XML形式导出svn log -v -r 14:17 > svn.xml --xmlsvn log -v -r 14:17 >> svn.xml --xml（二）svn diff用法: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...]2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \[PA TH...]3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]1、显示版本REV 中TARGET 在两个不同的版本之间的差异。
SVN搭建参考手册【详细说明+图片】
SVN搭建参考手册【详细说明+图片】一、SVN 服务器和客户端安装安装服务器程序运行服务端程序VisualSVN-Server-1.6.4.msi，根据提示安装即可，这样我们就有了一套在服务器端运行的环境。
安装客户端程序TortoiseSVN运行TortoiseSVN-1.6.4.16808-win32-svn-1.6.4.msi按照提示安装即可，不过最后完成后会提示是否重启，其实重启只是使svn工作拷贝在windows中的特殊样式生效，与所有的实际功能无关，这里为了立刻看到好的效果，还是重新启动机器。
安装客户端语言包运行LanguagePack_1.6.4.16808-win32-zh_CN.msi注意：上述服务端和客户端程序均为开源软件，在使用过程中注意两者版本的统一二、SVN 创建版本库多库管理模式SVNROOT为版本库的根目录，wendang为文档管理版本库、sourcecode为为各系统代码管理版本库。
VisualSVN-Server提供了一个可视化的控制台，通过它我们可以方便的完成版本库的创建和权限的分配工作。
1. 启动VisualSVN Server Manager，在VisualSVN Servers上右键选择Properties2. 在弹出的界面上设置版本库的根位置，设置完毕后会重新启动相关服务3. 在VisualSVN Servers上右键选择Creat New repository ，创建新的版本库，并在文本框中输入库名称上图中的CheckBox如果选中，则在库test下面会创建trunk、branches、tags 三个子目录；不选中，则只创建空的版本库test。
（注：VisualSVN Server Manager不支持对目录下文件的创建和删除操作，这项工作需要借助Tortoise SVN来完成）三、SVN 安全配置用户设置1. 启动VisualSVN Server Manager，右键点击界面上的Users文件夹，选择create user2. 在弹出的Users设置界面上添加新的用户和密码用户组设置1. 在VisualSVN Server Manager上右键点击界面上的Groups文件夹，选择create Group2. 在弹出的Gruop设置界面上添加新的组和组成员安全性设置1. 在版本库中选择一个库，右键选择Properties2. 点击上图中的"Add..."按钮，在下图中选择我们刚才添加的用户,点击OK按钮3. 按照下图所示，分别对用户或组进行授权在线修改密码1. 在安装目录（如C:\Program Files\VisualSVN Server\）的bin文件夹下增加alias.so、mod_cgi.so两个文件2. 在安装目录中增加cgi-bin文件夹，其中包含svnpass、svnpass.ini两个文件，修改svnpass.ini中pwdFilePath地址的指向为版包库中密码存放的文件，例如：pwdFilePath=D:\Repositories\htpasswd3. 修改安装目录中conf文件夹中的httpd-custom.conf，增加如下内容：LoadModule alias_module bin/mod_alias.soLoadModule cgi_module bin/mod_cgi.so<IfModule alias_module>ScriptAlias /cgi-bin/ "C:/Program Files/VisualSVN Server/cgi-bin/"</IfModule>4. 修改安装目录中htdocs文件夹的部分内容注意：上述所需文件参见SVN中相关附件5. 用户通过URL访问版本库，在验证通过后就能完成密码的在线修改四、SVN 备份恢复机制出于资源安全性考虑，为了防止由于配置管理服务器硬件或者软件故障，而导致配置库资源丢失且无法恢复的情况发生，需要对配置库资源进行定期的备份。
svn-分支和主干
SVN - 主干/分支一个大项目在开发中可能会拆分成几个小项目，分别分去，同时共通的部分再由人做，做完后再统一合并。
同时，在开发中，共通的部分修改后，其它人要保持同步。
这种情况反应到SVN的分支/合并功能上，再贴切不过了。
SVN可以为一个版本库中的内容(主干)建立一个分支.分支和主干完全独立，就相当于把代码再复制一份，重新添加到版本库中。
但SVN提供另一个功能，就是把主干做出的修改合并到分支中，以及把分支修改的内容合并到主干中。
当然，我们也可以把主干的版本库的路径切换到分支上，然后更新，来实现把分支的修改更新到主干；以及修改分支路径来同步主干的修改。
但过程复杂，还容易出错。
SVN 的分支功能还提供一些合并的测试，可以在不改动版本路径的情况下完成上面的需求。
示例:1.将一个整项目建一个分支.建立时要注意：1.当前复制源,即专业术语中的 "主干(truck)"2.分支存放的位置. 当然，分支也是在SVN版本库中.3.写上日志.这个大家应该懂的.4.是否把主干的路径切换到分支.如果勾选了，建立分支后，在主干里做出的修改并提交后，更新会提交到分支上。
主干的版本源内容不会变.这时我们看一下 trunk 目录的属性，可以看到它的路径已经变成:/calc/branches/my-calc-branch 了。
为了避免产生困惑。
以及失误。
在建立的时候不要勾上 "切换到分支" 的选项。
如果勾上了，我们还是切换回去:注意:1.主干的目录2.版本库源路径这时你便可以在 /calc/branches/my-calc-branch 分支上开发新的功能，且不会影响到其他成员开发或维护主干的内容。
2.合并主干的变更也许过了一段时间，原本的 /calc/trunk 主干可能已经有其他成员陆续修正了一些 Bugs，但这时你的分支 /calc/branches/my-calc-branch 就可以直接套用主干 ( /calc/trunk ) 的更新，除了避免重复的工作外，也可以避免版本的冲突，因为多人改同样的文件可能发生冲突。
VisualSVN Server的配置和使用方法
一、VisualSVN Server的配置和使用方法【服务器端】安装好VisualSVN Server后，运行VisualSVN Server Manger，下面是启动界面：好的，下面我来添加一个代码库【Repository】，如下图：按上图所示，创建新的代码库，在下图所示的文本框中输入代码库名称：注意：上图中的CheckBox如果选中，则在代码库StartKit下面会创建trunk、branches、tags 三个子目录；不选中，则只创建空的代码库StartKit。
点击OK按钮，代码库就创建成功了。
创建完代码库后，没有任何内容在里面。
我会在这个教程的第二部分说明如何迁入源代码。
下面，我们开始安全性设置，在左侧的Users上点击右键：输入上面的信息，点击OK，我们就创建一个用户了。
按照上面的过程，分别添加用户Developer1、tester1、manager1，好了，我们开始添加这些用户到我们刚才创建的项目里：点击上图中的"Add..."按钮，在下图中选择我们刚才添加的用户,点击OK按钮：说明：大家可能注意到了下图中的Groups，是的，你也可以先创建组，把用户添加到各个组中，然后对组进行授权，操作比较简单，在此略过。
按照下图所示，分别对用户【或组】进行授权：点击"确定"按钮，上面的用户就具有了访问StartKit代码库的不同权限。
因为用户starter在团队中是新来者，不希望他向代码库中提交新代码，所以他只能读取代码库中的代码，不能提交代码。
tester1是测试人员，不负责代码编写，所以也是只读权限。
而Developer1和manager1是开发人员和项目经理，自然具有读、写的权限。
在实际的项目开发过程中，Developer和tester往往不可能只有一个人，这时候使用组来授权更加方便，这个大家可以自己练习一下。
二、TotoiseSVN的基本使用方法在项目管理实践教程一、工欲善其事，必先利其器【Basic Tools】中，我已经讲解了怎样安装TortoiseSVN。
SVN常用命令详解
SVN常用命令详解SVN常用命令详解版本：1.0发布日期：2011-1-27实施日期：2011-1-27修订记录目录修订记录 (2)1.Svnadmin概述 (16)2.svnadmin 选项 (16)2.1.svnadmin list (17)2.1.1.摘要 (17)2.1.2.描述 (17)2.1.3.范例 (17)2.2.svnadmin create (18)2.2.1.摘要 (18)2.2.2.描述 (18)2.2.3.范例 (18)2.3.svnadmin dump (18)2.3.1.摘要 (18)2.3.2.描述 (19)2.3.3.范例 (19)2.4.svnadmin help (20)2.4.1.摘要 (20)2.4.2.描述 (20)2.5.svnadmin load (20)2.5.1.摘要 (20)2.5.2.描述 (20)2.5.3.范例 (20)2.6.svnadmin lstxns (20)2.6.1.摘要 (21)2.6.2.描述 (21)2.6.3.范例 (21)2.7.svnadmin recover (21)2.7.1.摘要 (21)2.7.2.描述 (21)2.7.3.Warning（注意：） (21)2.7.4.范例 (21)2.8.svnadmin rmtxns (22)2.8.1.摘要 (22)2.8.2.描述 (22)2.8.3.范例 (22)2.9.svnadmin setlog (22)2.9.1.摘要 (22)2.9.2.描述 (23)2.9.3.Warning（注意：） (23)2.9.4.范例 (23)3.svnlook (23)4.svnlook 选项 (23)4.1.svnlook author (24)4.1.1.摘要 (24)4.1.2.描述 (24)4.1.3.范例 (24)4.2.svnlook cat (25)4.2.1.摘要 (25)4.2.2.描述 (25)4.2.3.范例 (25)4.3.svnlook changed (25)4.3.1.摘要 (26)4.3.2.描述 (26)4.3.3.范例 (26)4.4.svnlook date (26)4.4.1.摘要 (26)4.4.2.描述 (26)4.4.3.范例 (27)4.5.svnlook diff (27)4.5.2.描述 (27)4.5.3.范例 (27)4.6.svnlook dirs-changed (28)4.6.1.摘要 (28)4.6.2.描述 (28)4.6.3.范例 (28)4.7.svnlook help (29)4.7.1.摘要 (29)4.7.2.描述 (29)4.8.svnlook history (29)4.8.1.摘要 (29)4.8.2.描述 (29)4.8.3.范例 (29)4.9.svnlook info (30)4.9.1.摘要 (30)4.9.2.描述 (30)4.9.3.范例 (31)4.10.svnlook log (31)4.10.1.摘要 (31)4.10.2.描述 (31)4.10.3.范例 (31)4.11.svnlook proplist (31)4.11.1.摘要 (32)4.11.2.描述 (32)4.11.3.范例 (32)4.12.svnlook tree (32)4.12.1.摘要 (32)4.12.2.范例 (33)4.13.svnlook youngest (33)4.13.2.描述 (33)4.13.3.范例 (33)5.Subversion 命令行客户端: svn (34)6.svn 选项 (34)6.1.--diff-cmd CMD (34)6.2.--diff3-cmd CMD (34)6.3.--dry-run (34)6.4.--editor-cmd CMD (35)6.5.--encoding ENC (35)6.6.--extensions (-x) "ARGS" (35)6.7.--file (-F) FILENAME (35)6.8.--force (35)6.9.--force-log (35)6.10.--help (-h 或 -?) (36)6.11.--notice-ancestry (36)6.12.--incremental (36)6.13.--message (-m) MESSAGE (36)6.14.--new ARG (36)6.15.--no-auth-cache (36)6.16.--no-diff-deleted (36)6.17.--no-ignore (37)6.18.--non-interactive (37)6.19.--non-recursive (-N) (37)6.20.--old ARG (37)6.21.--password PASS (37)6.22.--quiet (-q) (37)6.23.--recursive (-R) (37)6.24.--relocate FROM TO [PATH...] (38)6.25.--revision (-r) REV (38)6.26.--revprop (38)6.27.--show-updates (-u) (38)6.28.--stop-on-copy (38)6.29.--strict (39)6.30.--targets FILENAME (39)6.31.--usernameNAME (39)6.32.--verbose (39)6.33.--version (39)6.34.--xml (39)7.svn 子命令 (40)7.1.svn add (40)7.1.1.摘要 (40)7.1.2.描述 (40)7.1.3.替代名称 (40)7.1.4.更动 (40)7.1.5.选项 (40)7.1.6.范例 (40)7.2.svn cat (41)7.2.1.摘要 (41)7.2.2.描述 (41)7.2.3.替代名称 (41)7.2.4.更动 (41)7.2.5.存取档案库 (41)7.2.6.选项 (42)7.2.7.范例 (42)7.2.8.Tip (42)7.3.svn checkout (42)7.3.1.摘要 (42)7.3.2.描述 (43)7.3.3.替代名称 (43)7.3.5.存取档案库 (43)7.3.6.选项 (43)7.3.7.范例 (43)7.4.svn cleanup (45)7.4.1.摘要 (45)7.4.2.描述 (45)7.4.3.替代名称 (46)7.4.4.更动Changes (46)7.4.5.存取档案库 (46)7.4.6.选项: (46)7.4.7.范例 (46)7.5.svn commit (46)7.5.1.摘要 (46)7.5.2.描述 (46)7.5.3.Tip (47)7.5.4.替代名称 (47)7.5.5.更动 (47)7.5.6.存取档案库 (47)7.5.7.选项 (47)7.5.8.范例 (48)7.6.svn copy (49)7.6.1.摘要 (49)7.6.2.描述 (49)7.6.3.Warning (49)7.6.4.替代名称 (49)7.6.5.更动 (49)7.6.6.存取档案库 (50)7.6.7.选项 (50)7.6.8.范例 (50)7.7.svn delete (51)7.7.1.摘要 (51)7.7.2.描述 (52)7.7.3.替代名称 (52)7.7.4.更动 (52)7.7.5.存取档案库 (52)7.7.6.选项 (52)7.7.7.范例 (53)7.8.svn diff (53)7.8.1.摘要 (53)7.8.2.描述 (54)7.8.3.替代名称 (54)7.8.4.更动 (54)7.8.5.存取档案库 (54)7.8.6.选项 (54)7.8.7.范例 (55)7.9.svn export (56)7.9.1.摘要 (56)7.9.2.描述 (56)7.9.3.替代名称 (57)7.9.4.修改 (57)7.9.5.存取档案库 (57)7.9.6.选项 (57)7.9.7.范例 (57)7.10.svn help (58)7.10.1.摘要 (58)7.10.2.描述 (58)7.10.3.替代名称 (58)7.10.4.更动 (58)7.10.6.选项 (58)7.11.svn import (58)7.11.1.摘要 (59)7.11.2.描述 (59)7.11.3.替代名称 (59)7.11.4.更动 (59)7.11.5.存取档案库 (59)7.11.6.选项 (59)7.11.7.范例 (60)7.12.svn info (60)7.12.1.摘要 (60)7.12.2.描述 (60)7.12.3.替代名称 (61)7.12.4.更动 (61)7.12.5.存取档案库 (61)7.12.6.选项 (61)7.12.7.范例 (61)7.13.svn list (62)7.13.1.摘要 (62)7.13.2.描述 (62)7.13.3.替代名称 (63)7.13.4.更动 (63)7.13.5.存取档案库 (63)7.13.6.选项 (63)7.13.7.范例 (63)7.14.svn log (64)7.14.1.摘要 (64)7.14.2.描述 (64)7.14.3.替代名称 (65)7.14.4.更动 (65)7.14.5.存取档案库 (65)7.14.6.选项 (65)7.14.7.范例 (65)7.15.svn merge (69)7.15.1.摘要 (69)7.15.2.描述 (70)7.15.3.替代名称 (70)7.15.4.更动 (70)7.15.5.存取档案库 (70)7.15.6.选项 (70)7.15.7.范例 (71)7.16.svn mkdir (71)7.16.1.摘要 (71)7.16.2.描述 (71)7.16.3.替代名称 (72)7.16.4.更动 (72)7.16.5.存取档案库 (72)7.16.6.选项 (72)7.16.7.范例 (72)7.17.svn move (73)7.17.1.摘要 (73)7.17.2.描述 (73)7.17.3.Tip (73)7.17.4.Warning (73)7.17.5.替代名称 (73)7.17.6.更动 (73)7.17.7.存取档案库 (74)7.17.8.选项 (74)7.17.9.范例 (74)7.18.svn propdel (74)7.18.1.摘要 (75)7.18.2.描述 (75)7.18.3.替代名称 (75)7.18.4.更动 (75)7.18.5.存取档案库 (75)7.18.6.选项 (75)7.18.7.范例 (75)7.19.svn propedit (76)7.19.1.摘要 (76)7.19.2.描述 (76)7.19.3.替代名称 (76)7.19.4.更动 (76)7.19.5.存取档案库 (76)7.19.6.选项 (76)7.19.7.范例 (77)7.20.svn propget (77)7.20.1.摘要 (77)7.20.2.描述 (77)7.20.3.替代名称 (77)7.20.4.更动 (77)7.20.5.存取档案库 (78)7.20.6.选项 (78)7.20.7.范例 (78)7.21.svn proplist (78)7.21.1.摘要 (78)7.21.2.描述 (78)7.21.3.替代名称 (79)7.21.4.更动 (79)7.21.5.存取档案库 (79)7.21.6.选项 (79)7.21.7.范例 (79)7.22.svn propset (80)7.22.1.摘要 (80)7.22.2.描述 (80)7.22.3.Tip (80)7.22.4.替代名称 (80)7.22.5.更动 (80)7.22.6.存取档案库 (80)7.22.7.选项 (80)7.22.8.范例 (81)7.22.9.Warning (82)7.23.svn resolved (82)7.23.1.摘要 (82)7.23.2.描述 (82)7.23.3.替代名称 (82)7.23.4.更动 (82)7.23.5.存取档案库 (82)7.23.6.选项 (82)7.23.7.范例 (83)7.23.8.Warning (83)7.24.svn revert (83)7.24.1.摘要 (83)7.24.2.描述 (83)7.24.3.替代名称 (84)7.24.4.更动 (84)7.24.5.存取档案库 (84)7.24.6.选项 (84)7.24.7.范例 (84)7.24.8.Warning (85)7.25.svn status (85)7.25.1.摘要 (85)7.25.2.描述 (85)7.25.3.替代名称 (87)7.25.4.更动 (87)7.25.5.存取档案库 (87)7.25.6.选项 (88)7.25.7.范例 (88)7.25.8.Warning (88)7.26.svn switch (89)7.26.1.摘要 (89)7.26.2.描述 (89)7.26.3.替代名称 (89)7.26.4.更动 (89)7.26.5.存取档案库 (90)7.26.6.选项 (90)7.26.7.范例 (90)7.26.8.Tip (91)7.27.svn update (91)7.27.1.摘要 (91)7.27.2.描述 (92)7.27.3.替代名称 (92)7.27.4.更动 (92)7.27.5.存取档案库 (92)7.27.6.选项 (92)7.27.7.范例 (93)7.27.8.Tip (93)1.Svnadmin概述svnadmin 是用来监控与修复 Subversion 档案库的管理工具。
SVN库迁移整理方法总结
SVN库迁移整理方法总结前段时间对项目SVN库做整理, 顺带再次研究了下SVN迁移的方式,整理如下:SVN数据库迁移方法一称之为SVN全库操作,或称SVN全局备份并恢复，版本库数据的移植:svnadmin dump、svnadmin load导出:$svnadmin dump repos > dumpfile //将指定的版本库导出成文件dumpfile新建:$svnadmin create newrepos导入:$svnadmin load newrepos < dumpfileSVN数据库迁移方法二增量备份或批次备份,批次恢复，特定reversion导出:$svnadmin dump repos –r 23 >rev-23.dumpfile //将version23导出$svnadmin dump repos –r 100:200 >rev-100-200.dumpfile //将version100~200导出批次导出:对比较大的库可以批次导出，便于备份$svnadmin dump repos –r 0:1000 >0-1000.dumpfile$svnadmin dump repos –r 1001:2000 --incremental >1001-2000.dumpfile$svnadmin dump repos –r 2001:3000 --incremental >2001:3000.dumpfile批次导入，将这几个备份文件装载到一个新的版本库中$svnadmin load newrepos < 0-1000.dumpfile$svnadmin load newrepos < 1001-2000.dumpfile$svnadmin load newrepos < 2001:3000.dumpfileSVN数据库迁移方法三导出后,在导入时对库做分库整理或其它整理操作过滤版本库历史:假设有一个包含三个项目的版本库：calc，calendar，和spreadsheet。
SVN分支与合并【超详细的图文教程】
SVN分支与合并一、分支与合并的概念二、SVN分支的意义三、如何创建分支与合并分支一、分支与合并的概念：分支：版本控制系统的一个特性是能够把各种修改分离出来放在开发品的一个分割线上。
这条线被称为分支。
分支经常被用来试验新的特性，而不会对开发有编译错误的干扰。
当新的特性足够稳定之后，开发品的分支就可以混合回主分支里(主干线)。
合并：分支用来维护独立的开发支线，在一些阶段，你可能需要将分支上的修改合并到最新版本，或者将最新版本的修改合并到分支。
二、SVN分支的意义：简单说，分支就是用于区分开发版本与当前发布版本的。
1、主干负责新功能的开发2.、分支负责修正当前发布版本的bug（对于可以放入下个发布版本的改进性bug可以直接在主干上开发）3.、分支上修改的bug，经常性merge到主干上，尽量及时merge（避免大面积红色区域）。
4.、只能分支往主干靠拢（merge），不能反向！5.、直到下个新版本发布，该分支停止修改三、如何创建分支与合并分支：1、首先要在你的版本库存里创建主干目录，通过版本库浏览器，如图1所示：（图1）2、输入版本库URL地址，如图2所示：（图2）3、进入版本库浏览器主目录，如图3所示：（图3）4、创建主干目录，如图4所示：（图4）5、主干目录（trunck），如图5所示：（图5）6、把你要加入版本控制的文件加入主干，如图6-8所示：（图6）（图7）（图8）7、从主干里检出文件到你的本地工作副本上，如图9-10所示：（图9）（图10）8、选择你要创建分支的工作副本,如图11所示：（图11）9、在“至URL”里填写版本库中要存放分支的目录，如图12-13所示：（图12）（图13）注意：这时候工作副本对应版本库的路径仍为原来对应的主干的目录。
10、再从分支里检出内容到本地目录上，如图14-15所示：（图14）（图15）11、打开刚从分支里检出的工作副本目录，修改里面的test.txt文档并提交，如图16-17所示：（图16）（图17）注意：这时提交的修改只会提交到分支上，并不会更改主干上的内容。
idea svn合并分支命令
1. 介绍SVN合并分支命令的背景和作用SVN（Subversion）是一种流行的版本控制系统，用于管理文件和目录的版本。
在软件开发过程中，通常会使用分支来并行开发不同的功能或修复不同的bug，而SVN合并分支命令则可以将不同的分支合并为一个统一的版本。
在实际开发中，正确使用SVN合并分支命令可以帮助团队更好地协作，提高代码的质量和效率。
2. SVN合并分支命令的基本用法SVN合并分支命令的基本用法包括两种情况：一是从一个分支合并到另一个分支，二是从一个分支合并回主干。
下面将分别介绍这两种情况下的基本用法及步骤。
3. 从一个分支合并到另一个分支当需要将一个已经开发完成的功能或修复的bug合并到另一个分支时，可以按照以下步骤进行操作：步骤一：切换到需要接受变更的目标分支首先需要使用svn switch命令切换到需要接受变更的目标分支，例如：svn switch ^/branches/new_feature步骤二：使用svn merge命令进行合并然后使用svn merge命令将源分支的变更合并到目标分支，例如：svn merge ^/branches/feature_1步骤三：确认合并变更最后需要确认和解决合并中的冲突，并进行提交到目标分支，完成合并操作。
4. 从一个分支合并回主干当一个分支上的开发完成后，需要将其合并回主干时，可以按照以下步骤进行操作：步骤一：切换到主干首先需要使用svn switch命令切换到主干，例如：svn switch ^/trunk步骤二：使用svn merge命令进行合并然后使用svn merge命令将分支的变更合并到主干，例如：svn merge ^/branches/feature_1步骤三：确认合并变更最后需要确认和解决合并中的冲突，并进行提交到主干，完成合并操作。
5. SVN合并分支命令的注意事项在使用SVN合并分支命令时，需要注意以下几点：1）在合并前，需要确保分支上的变更已经被提交到版本库，并且目标分支是最新的；2）在合并中可能会出现冲突，需要及时解决并确认合并变更；3）合并后可能会导致代码的冲突或bug，需要进行充分的测试和验证；4）对于重要或复杂的合并操作，建议在合并前进行备份或创建临时分支进行测试。
补丁包管理规定
补丁包管理规定集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#补丁包管理办法名词术语1、补丁包：由公司统一规划版本的补丁程序。
2、临时补丁包：由紧急任务引起，临时发布的补丁程序。
角色和职责1、产品经理：➢负责版本规划、版本范围变更，制定总体目标和计划。
2、版本经理：➢负责补丁包的开发、测试、补丁包生成等工作，制订详细的工作分解计划。
3、发布管理员：➢负责补丁包开发过程中发布测试版本。
补丁包命名1、基线版本命名格式为：项目名称V版本号，例：2、补丁包命名格式为：项目名称V版本号SP编号，例：3、临时补丁包命名格式为：项目名称V版本号SP编号_L编号，例：整体流程版本规划1、产品经理（指开发部门经理）收集需求和缺陷，并组织对需求和缺陷的评审，形成评审结果，具体分为：（1）接收并指定实现版本；（2）拒绝同时给出拒绝原因；2、产品经理根据公司、客户等多方面的要求，制定每个版本的开发周期，并指定版本经理。
版本经理根据每个版本的开发范围合理安排开发、测试计划，如有变化，请及时和产品经理沟通以便进行版本开发范围或计划的变更。
补丁的开发、测试1、补丁包（1）将补丁包开发作为一个项目，由产品经理指定版本经理负责补丁包的开发、测试、补丁包生成和申请发布工作。
（2）补丁包的开发、测试、补丁包生成和申请发布工作由版本经理负责组织制定详细的工作分解计划。
（3）补丁包的测试版本发布由版本经理指定版本管理员负责，发布测试版本时要合并与上一个补丁包之间的所有临时补丁。
（4）测试完成后版本经理组织将分支合并到主干，解决冲突后生成补丁包。
（5）补丁包采用兼容性补丁模式，即：补丁包均是基于trunk的增量包，后面的补丁兼容前面的补丁。
（与兼容性补丁相对应的就是独立补丁，补丁包均是基于trunk的增量包，后面的补丁不兼容前面的补丁，各个补丁间是独立的；）注：制作增量补丁包的方法见附件22、临时补丁包（1）由开发部经理指定人员负责开发。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
SVN中trunk,branches,tags用法详解
Subversion有一个很标准的目录结构，是这样的。
比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是
svn://proj/|+-trunk+-branches+-tags
这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许
修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。
对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发（比如freebsd），因
为互联网的开发模式是完全不一样的。 1.第一种方法，使用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永远是开发的主要目录。
2.第二种方法，在每一个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的分支上修复