Behind the Code » subversion

如何使用svn进行merge

yinwm — Wed, 09 Apr 2008 08:45:48 +0000

svn 的
merge其实很好用，当然前提是你明白了svn merge这个命令，还好，我用了大约一年明白了这个命令 -___-!!

跟大家说一下用法，比如我们要把分支merge到主干上

# svn merge –help
merge: Apply the differences between two sources to a working copy path.
usage: 1. merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
2. merge sourceWCPATH1@N sourceWCPATH2@M [WCPATH]
3. merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]

我们以第一个为例
merge sourceURL1[@N] sourceURL2[@M] [WCPATH]
这个help里面提示，merge需要三个参数
sourceURL1，sourceURL2的含义并不是两个分支，或者一个分支一个主干，而是同一个分支的两个状态，或者说是两个版本。对这两个版本做一个diff，然后把diff的结果，应用到最后的参数WCPATH上，WCPATH代表是一个本地已经checkout的工作区

svn merge的思想是diff and apply

比如，我开发一个项目叫做proj
目录结构是
proj/trunk
proj/branches
proj/tags

(省略了http:// 之后的，只是相对路径，但是真正使用时候不能省略)

当版本达到100的时候，我决定做一个branch进行一些其他开发

[Reversion:100]
$svn cp proj/trunk proj/branches/proj_branch_1
OK Reversion:101

然后，trunk和proj_branch_1都在开发，到了某一个版本，比如150，branch开发完成，需要merge回到trunk
此时的目录结构是
[Reversion:150]
proj/trunk
proj/branches/proj_branch_1
proj/tags

按照svn的实现，我需要知道proj_branch_1所做的所有的变化，也就是当前的状态对刚刚生成时候状态的变化。根据这个变化生成一个diff文件，在apply一个本地的工作区上。（建议是一个干净的本地trunk工作区）

那么执行
$cd proj/trunk
$svn merge proj/branches/proj_branch_1@101 proj/branches/proj_branch_1 .

其实，第一个URL（我们称之为左边），为起始状态，通过最后的@101，表示取版本101，这个101就是cp成功之后的那个版本。第二个URL（我们称之为右边），为最终状态，取最新的，
左边和右边做了一个diff，应用到当前工作区目录，也就是trunk。
此时
$svn st就可以看到变化了

这里的一个问题是如何获取这个cp之后的版本，也就是例子中的101
可以使用svn log里面的–stop-on-copy命令
$svn log –stop-on-copy proj/branches/proj_branch_1
会到cp的时候停下来，那里边标注的版本就是需要的版本

比如，这是一个真正项目的一个例子，
————————————————————————
r995 | yinweiming | 2007-10-24 09:07:08 +0800 (三, 24 10月 2007) | 1 line

Create a branch for proj client using
————————————————————————
其中的r995，995就是我需要的版本
（说明一下，commit时候写commet的好处，比如这里我就很明确的肯定这是branch的起始点）

对于svn merge的另外的用法也是类似，只要是明白了
他是根据左边，右边生成diff，然后应用到本地的一个工作区就容易理解了。

还有可以使用svn merge –dry-run来模拟假装merge一下，看一下merge会发生什么，而不是真正的做这个动作。

而对于merge的help里面的 3. merge [-c M | -r N:M] SOURCE[@REV] [WCPATH]
这个也很容易理解，就是取 SOURCE 这个东西，版本N，M之间的区别，作用在WCPATH这个本地工作区上

注意！
做branch千万别根据本地修改过的工作区做，一定基于某一个URL的版本做

我就吃过这个亏
diff的时候，diff不出来，因为基于本地工作区的，所以现在merge起来很是费劲

为什么使用DVCS

yinwm — Thu, 21 Feb 2008 23:25:30 +0000

我们在开发过程中一般都使用VCS工具，最普遍的工具就是svn，但是在使用过程中还是会存在一些问题的。

假设一个场景
一个项目要进行开发，

A是底层核心功能开发人员，他要对底层进行开发，并且在第一时间所有的人都要获取他的代码
B是功能开发人员，进行一个feature1的开发
C，D是功能开发人员，进行另外一个feature2的开发
feature1和feature2要公用部分代码，比如同一个接口文件，并对他进行修改

假如我们用svn进行开发，这里面是有一个问题的，因为A的存在，feature1和feature2的开发并不能完全分开，而在开发阶段B，C，D三个人都不能随意的提交代码，否则feature1和feature2都会相互影响。如果他们真的都是分开的功能也没问题，但是因为C，D是一个feature的负责人，他们之间必须要进行代码交换，而因为svn是集中式开发，那么他们应该，必须，也只能通过svn进行代码交换。
如果

C提交代码，要求D更新代码
A提交代码，要求所有人更新代码
D获取代码，A和C的，是正确的代码
B获取代码，死菜了，因为C的代码是他不需要的，会影响他的工作，甚至都无法编译通过

这个是一个很普遍的场景，尤其是对人数多一些的小组。那么我们应该如何避免这种情况的发生呢？答案是使用DVCS系统，也就是分布式代码管理系统，例如bzr，hg等。

DVCS的出现可以方便的解决这类问题。与svn等传统VCS系统不同，DVCS并不需要一个中心服务器，每个人的开发工作区都可以认为是中心服务器。DVCS的基础是分支，每需要一个开发工作区，都是基于已有的某个开发工作区创建一个分支，然后开发，然后进行分支的代码merge。因为这种特性，DVCS的分支操作代价非常小。当然对于管理，发布等等我们还是需要一个中心服务器的，那么我们只要一个放在中心服务器的分支就足够了，使用完全相同的技术和下面的各个开发工作区进行代码交换。从技术上，他们的地位是完全等同的。
根据这些，我们再使用DVCS假设一下上述的开发场景

在中心服务器创建技术开发版本
A，B，C，D分别根据中心服务器创建自己的开发分支
A进行开发，每个阶段，B，C，D基于A提供的代码进行merge，比如A自己架设一个（临时的）ftp
C进行开发，每一阶段，D基于C提供的代码进行merge，相对D的开发来说，情况一样。他们的开发完全不影响B的开发
最终都开发完成，一并merge回中心服务器

这就非常顺利的避免了上面遇到的问题。而且，DVCS因为是把自己的工作区认为是代码仓库（repository），所以可以随时的提交代码，随时记录自己的开发变更。而这个在svn当中有时就比较头疼，如果一个feature要开发时间比较长，那么中间的每一个小阶段的代码就很难记录了。

当然了，你可以说，我在svn当中采用给每个人开分支的方法解决这个问题。bingo，没错，但是，这已经就是DVCS的思想了，不是么？那么为什么不用一个现成的DVCS工具呢？

使用svn—-和IDE配合

yinwm — Sat, 19 Jan 2008 08:00:15 +0000

不知道你有没有过使用IDE来配合Subversion的经历，比如eclipse啊之流。这些IDE为了对自己的项目进行管理，都回生成一些放在项目下的配置文件，比如eclipse的`.classpath`文件。如果你使用svn，一个不小心就会把这些文件传回代码库，对你自己当然是无所谓了，但是别人就惨了。因为别人在checkout的时候，不得不使用你的配置，而如果别人也和你一样的使用eclipse这种和svn的配合方法，他就更惨了。因为up下来的配置文件和本地的冲突，然后最坏的情况就是你的项目死菜了。况且，这些文件并不是开发的项目的一部分，也不应该和代码放在一起。
这是一个很普遍的问题，那么如何来解决呢？使用我们前面说的外部定义。
svn标准的目录结构为
svn://proj/
             +trunk
             +branches
             +tags
在这里我们添加一个管理个人私有文件的目录，privates，当然了，这些IDE的配置文件也是私有文件咯。
svn://proj/
             +trunk
             +branches
             +tags
             +privates

这个privates目录如何使用呢？我们首先在下面建立自己的目录，比如/privates/yinwm，此时我的所有的私有文件都应该放在这里。然后再根据自己所要开发的目录结构（trunk还是分支）建立对应的目录，比如/privates/yinwm/trunk，/privates/yinwm/dev_1.0。
使用IDE，checkout这个目录，此时这个目录下是任何文件都没有的，并且它只属于你自己。当成功的checkout之后，建立外部定义，让一个内部目录（我喜欢起名字叫proj）指向对应的开发目录（trunk或者某一个branch）。再update，你的代码就下来了。此时你再通过IDE上传东西，代码会放在对应的代码区域，而配置文件会放入你自己的私人文件夹。这样就不会相互影响了。

目录结构如下：
svn://proj/
            +trunk/
            +branches/
                      +dev_1.0
                      +dev_2.0
            +tags/
            +privates/
                       +yinwm/
                                 +trunk/
                                          +.classpath等（IDE文件）
                                          +proj （外部定义，指向trunk）
                                 +dev_1.0/
                                          +.classpath等（IDE文件）
                                          +proj （外部定义，指向branches/dev_1.0）
                       +xxx

这样大家就可以方便的工作了。当然，如果你是console+editor达人（我是70%的这类达人，:D，hoho），你就可以直接checkout trunk或者branch开发，反正这里也没有什么私人配置文件的问题。

使用svn——项目的目录布局

yinwm — Sat, 19 Jan 2008 06:34:40 +0000

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

svn://proj/
|
+-trunk
+-branches
+-tags

这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。

对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发（比如freebsd），因为互联网的开发模式是完全不一样的。
第一种方法，使用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——属性

yinwm — Mon, 07 Jan 2008 07:31:59 +0000

svn的属性可以说是一个非常好的创意，他是代码非常好的一种补充。
属性是外部不可见的，你可以简单的认为他就是一个文件的一个信息，和文件大小之类的信息是一样的，只不过他是通过svn来管理的。

从我个人的角度，我认为绝大多数的属性是给程序看的用的，因为他们更加的亲和svn的工具。比如我可以给文件添加一个属性叫做License，然后把我期望的属性填充进去。
属性相关的操作有propset，propget，proplist，propdel等。具体命令如下
$svn propset prop_name value
$svn propget prop_name filename
$svn proplist filename
$svn propdel prop_name filename

其中对我们来说有一些实际意义的属性是svn提供的一些特殊属性，这些属性是有特殊的含义的。我认为对我来说最常用的是
svn:keywords 给文件定义一些关键字，比如Author，LastChangedDate等
svn:mime-type 给文件定义mime-type，其中如果是二进制的mime-type则svn会针对文件进行二进制操作
svn:eol-stype 给文件定义如何定义行结束符，是windows形式的或者unix形式的，或者根据系统自动选择，一般都是设置成为自动选择，也就是value是native
svn:externals 这个昨天我介绍过，就是外部定义，请参阅使用svn——外部定义

一般对于这些属性的定义，可以使用svn propset，但是对于一些属性，比如svn:keywods,
svn:eol-style这些几乎每个文件都要定义的属性，如果一个一个的定义，手就残了。bingo，有人想到了写一个shell脚本，的确是个好主
意，但是每次都需要执行，也很烦。svn提供了一个形式，可以让你在对文件进行管理的时候，自动进行属性的添加。也就是修改svn的config文件的
[auto-props]这部分。
svn的config文件请参阅“config”一节才，（文件存放的位置是，linux是$HOME/.subversion/config，windows通常放在是c:\documents and settings\%user%\application data\subverion\config）
一般的，我们需要设置的属性，按照这个形式书写
file-pattern = prop-name=value
例如
.* = svn:eol-style=native
这就是说明无论是什么样子的文件名，都设置上svn:eol-style这个属性，属性的值为native。

这几基本上说了一些关于svn属性的东西，具体的文档可以参阅svn的属性章节

也许有一些同学发现其实svn:keywords这个东西很值得说，是的，但是之所以我这里不表，是因为更多的我认为他应该属于svn规范的一部分，所以稍后再说。如果有同学想看看，那么去这个地方了解一下也好。

使用svn——外部定义

yinwm — Fri, 04 Jan 2008 08:28:44 +0000

在svn中提供了一个非常好的功能叫做外部定义，简单的说就是可以把外部的svn版本库映射到一个目录。这是一个本身很简单的功能，但是他却能给svn的使用和管理带来很多多变的功能。

首先详细的解释一下外部定义这个功能吧。我们用一个用户的使用场景来说明一下。说的尽量的详细，所以比较啰嗦:)。
假设现在有两个团队，一个是开发组（dev-team），一个是文档组（doc-team），共同开发一个产品。这两个小组各自有各自的管理等等原因，所
以分开使用svn比较好，所以共有两个svn版本库，dev-svn和doc-svn。我们假设这两个版本库都使用标准的组织结构（详细对组织结构的讨论
请看以后的文章），现在的开发都是在trunk进行的。开发组，trunk下的目录组织为src，lib，build等等。
对于两个小组的开发，测试，管理，分开使用没有任何问题，也不会相互的有影响。但是面对最终产品发布的时候，要做安装程序，这时候就必须同时操作两个项
目。而很明显的一个普遍的组织结构就是doc-team开发的文档作为dev-team开发的程序等等的一部分。那么在dev-svn的trunk下，就
应该有一个叫做doc的目录，目录的内容是doc-svn的trunk的内容。
此时，我们就可以利用svn的外部定义功能来完成这个任务。svn的外部定义，其实是给（父）目录加上的一个属性（svn properties，详情后文介绍），这个属性定义了要引用哪个外部的版本库并且放在（父）目录下的哪个（子）目录中。
给父目录添加一个叫做svn:externals的属性，属性的内容是doc-name svn-url，svn-url表示要引用哪个svn的连接，doc-name表示这个引用放在哪个目录下
在上面的场景中，我们要给dev-svn的trunk目录设置一个属性sv:externals，属性的值是doc

http://doc-svn/trunk，这样当你设置完之后，update一下本地工作区，biu的一下，doc就过来了，这时候从dev-svn的

trunk的角度看，就有了完整的内容，包括doc。
完整的命令是，在chechout下来的dev-svn的trunk目录下
#svn propset svn:externals “doc http://doc-svn/trunk” .
propset，表示使用propset命令，添加属性
svn:externals，表示要添加svn:externals属性
“doc http://doc-svn/trunk”，表示要给这个属性添加的值，因为这个属性包含空格，所以要用双引号括起来
之后的点，表示要把这个属性添加在本目录上

啰嗦了一通，想必大家看的也是云山雾罩的，自己做个试验就可以了。

一些高级的外部定义的用法，我们对一个目录不但可以定义一个外部定义，还可以定义多个。比如doc来自doc-svn，website来自web-svn等等。这时候我们需要把这些东西都作为svn:externals的属性值。
doc http://doc-svn/trunk
website http://web-svn/trunk
注意！这里是需要换行的，这个对于命令行来说，是非常痛苦的，而且外部定义这种值里面还包含空格的需要用双引号括起来的值来说，就是痛苦死了。好吧，我承认我到现在也没有成功的设置过。怎么办？好吧，我们可以用另外的方法来搞定。
svn propset这个命令可以使用一个外部文件的文件内容作为给属性添加的值。命令如下
svn propset svn:externals -F filename .
所以，一般的，凡是需要用到这类用法的地方，我都会生成一个文件叫做LINKS，放到svn上管理。LINKS的内容如下
doc http://doc-svn/trunk
website http://web-svn/trunk
这样我们就可以使用svn propset svn:externals -F LINKS . 这个命令来设置了。

对属性的替换，直接set一个其他的值就好了。可是，如果我们不想要这个外部定义了怎么办？注意！这里千万不能使用svn del命令（比如在dev-svn的trunk目录下执行svn del doc），这样你删除的不是这个外部定义，而是你引用的svn版本库的内容。如果很幸运的，你是在另外的项目有写入的权限，好了，恭喜你，你已经把那个项目咔嚓掉了。
正确的做法是使用svn propdel命令来删除掉svn:externals这个属性
svn propdel svn:externals

最后还要提醒一点，这个属性是放在这个目录上的，对于svn来说，目录也是受到管理的，目录和目录内的文件之类的是不同的。所以你如果只想对这个目
录进行操作，而不像对它下面的文件进行操作，使用svn的时候，记得加上-N参数。比如类似svn:externals这样的属性就是针对目录的。

其实外部定义，还有很多的高级的使用功能，具体的我就不详述了，请参阅svn的帮助或者阅读文档，http://svndoc.iusesvn.com/svnbook/1.2/svn.advanced.externals.html。最新的文档（针对1.4，1.5的）是英文的，嘿嘿。

外部定义还有一些玩法，更多的还是在使用在基于svn管理的项目组织上，这个我会在以后的文章进行说明。