|
我们组要使用SVN共同维护，我写的一个说明文档，大家多指正：） 前言： 我是SVN初级玩家，只是结合SVN官方的文档以及网上的一点资料写的这个文档，目的是通过实际例子方便大家迅速掌握SVN，SVN官方文档很厚，而常用命令并不多，没有必要查看全部官方文档，水平有限，请多指正。 一、SVN基础介绍： 1.1 SVN是什么？ Subversion 是一个自由/开源的版本控制系统。也就是说,在 Subversion 管理下,文件和目录可以超越时空。也就是 Subversion 允许你数据恢复到早期版本,或者是检查数据修改的历史。正因为如此,许多人将版本控制系统当作一种神奇的“时间机器”。 SVN确实可以像一个时间机器一样，回到任意时刻的版本，查看任意两个时刻的版本变动，不止在协同开发中，即使在个人开发过程中，这种特性都是非常非常有用的，我曾经有过这种经历，对代码进行很多的修改，发现修改的想法根本是错误的，而这时我已经修改了多个文件，要想回退是非常纠结的事情，而现在可以使用SVN轻松做到这一点。 1.2 SVN是“正确的工具吗”？ 如果你是一个考虑如何使用 Subversion 的用户或管理员,你要问自己的第一件事就是: "这是这项工作的正确工具吗?",Subversion 是一个梦幻般的锤子,但要小心不要把任何问题当作钉子。如果你希望归档文件和目录旧版本,有可能要恢复或需要查看日志获得其修改的历史,那么Subversion 是你需要的工具。如果你需要和别人协作文档(通常通过网络)并跟踪所做的修改,那么Subversion 也适合。这是 Subversion 为什么使用在软件开发环境—编程是天生的社会活动,Subversion 使得与其他程序员的交互变得简单。当然,使用 Subversion 也有代价:管理负担。你会需要管理一个存放所有历史的数据版本库,并需要经常的备份。而在日常的工作中,你不能像往常一样复制, 移动, 重命名或删除文件,相反,你需要通过 Subversion 完成这些工作。 1.3 SVN的架构 SVN是一个典型的C/S架构，服务端维护全部数据以及更改的记录，客户端维护一个本地的工作副本。 1.4 SVN的“拷贝-修改-合并”方案（图片顺序先横向后纵向）
1.3 推荐的SVN布局安排 SVN服务器对布局没有任何限制，但是一种推荐的目录组织形式（我个人感觉比较好）是： / calc/ trunk/ tags/ branches/ calendar/ trunk/ tags/ branches/ … 其中/是主文件系统，cal和calendar是两个项目，在每个项目下有trunk、tags、branches文件夹其中： trunk保存的是主开发版 tags的是一些快照，比如发布1.0版本的时候，把trunk中的内容复制到tags/release-1.0下，然后可以对trunk内代码进行继续开发，不耽误用户使用1.0的稳定版 branches保存分支版本，比如一个项目的开发过程中，我想加入一些新特性或者 功能，这些功能又不是短时间能够完成的，但我又不想耽误到其他成员对主版本的开发，这是我需要在branches里建立一个分支，这个分支可以随时融合主版本的最新更改，保持同步，这样的优势是，比如其他成员对主版本一些bug进行了修复，我可以及时融入到我的分支版本中，最后在我的分支版本完成后，把分支版本融入到trunk版本中，并删除分支版本。 二、SVN实践 2.1 准备工作 首先安装SVN客户端、服务端软件。客户端软件用来维护和管理SVN本地代码，并与服务端软件交互，服务端软件用来建立一个SVN服务器，通常来说我们实验室的SVN服务器由实验室网管管理，我们不用负责服务端，但是这里为了练习需要，需要在本地建立一个测试服务端。另外这里只讨论基于命令行的应用。 2.2 建立一个服务端 首先在本地建立一个测试项目proj1
然后建立一个服务端（这个报告里面唯一需要使用服务端的地方），使用命令： svnadmin create repos 2.3 把本地项目导入服务端
注意-m后面加入一句话作为你的注释，如果你觉得一句话不够，可以不加-m，svn会引导你进入默认的编辑器中编辑你的注释。SVN中的注释非常非常重要，他可以让其他程序员（包括你自己）在不阅读很多代码的情况下了解改动，任何优秀的版本管理软件也比不上程序员的注释！ 这里把proj1导入了服务器之后，proj1目录并不能和svn服务器沟通，因为它不是一个工作副本。仍然需要导出一个工作副本和服务器进行通信：
并进入到导出的目录中，开始进一步的练习。 2.4 SVN基本操作 这里插两个SVN操作的原则先： 所有update（更新本地副本，从服务器端“拉”数据）和commit（提交本地修改到服务器，向服务器端“推”数据）都是原子的，要么所有不同文件的变更结束，要么所有变更都不发生。 “推”动作不会导致“拉”,反之亦然,因为你准备好了提交你的修改并不意味着你已经准备好了从其他人那里接受修改. 下面开始熟悉SVN的基本操作 1）为了达到测试协同开发的效果，我在2.3步骤中导入一个本地副本myprj后，我再次导入一个本地副本myprj2，使用命令： svn checkout file:///tmp/repos/trunk myproj2 2）我首先在myprj目录下更改文件a.txt，然后查看了本地的文件情况，最后向服务器提交我的更改：
运行语句svn status，看到在a.txt前标示了一个M，M表示这个文件被修改了。 3）去myprj2目录下，因为这个目录的文件已经旧了我需要跟服务器同步一下，以保持我本地副本是最新的
这里请注意版本号的变化，第一次导出的时候是revsion1，现在经过修改后最新的版本号是2，以后会用到基于版本号恢复文件的操作。 1）增加删除文件以及目录管理
首先我创建了一个aa.txt文件，然后我把aa.txt加入到svn版本管理中来，并把以前的a.txt删除了，又把c.txt复制了一份到cc.txt，建立了一个自文件夹subdir，你也可以直接用操作系统命令建立文件夹，再使用svn add把文件夹加入到版本管理中来。最后别忘了commit。 2）查看变更 首先我修改了cc.txt文件，然后使用了svn diff命令查看我做了哪些修改，可以看到我在cc.txt文件中加入了一句“hello cc”，这是以补丁的形式给出的所以我可以把它重定向为一个补丁文件，我还是用了svn status查看哪些文件被修改了。
3） 解决冲突
我首先提交了我之前的所有变更，然后进入到myprj目录进行了update，然后修改了myprj中的aa.txt文件并commit，之后回到myprj2目录修改aa.txt，并直接commit，这时commit报错了，提醒我我的版本号太低了，这种情况必须先update到最新的版本，然后才能提交新的变更（见SVN的“拷贝-修改-合并”方案图）。所以我执行了svn update命令，然后发现了aa.txt和我的本地经过修改的aa.txt冲突了。这时SVN给了我几个选择： p，稍后处理，我个人认为这个是最理想的方案，你可以通过svn log aa.txt命令发现到底是谁修改了aa.txt这个文件，找到那个人沟通一下然后手动合并你们的内容，再提交。 df可以通过这个命令显示你的版本和服务器版本到底有什么不同（以补丁的形式）。 e可以进行一些编辑，svn会帮助你保存到本地文件 mc是以我的当前副本的为准，无视覆盖别人的改动 tc是以服务器上的版本为准，放弃我的改动。 假设我之前选择了延后处理冲突，并和其他程序员协商之后，由我手动修改aa.txt：
我修改aa.txt之后，告诉svn我已经解决了冲突，然后commit 6）查看日志 就像前面提到的，日志是非常重要的一环。可以使用svn log来查看所有的log记录，然后可以通过-r 选项指定一个区间的日志内容查看HEAD是指最新的log，也可以加一个文件名，只看和这个文件相关的log
7）使用diff比较不同 前面已经介绍过使用svn diff查看本地的修改（以补丁形式）。svn diff还可以比较工作副本和版本库中某一特定版本的不同，也可以比较版本库中不同版本的异同。
8）查看svn版本库 Svn cat filename命令可以查看当前版本的filename中的内容，加上-r之后可以查看在指定版本中，filename文件的内容。
svn list http://svn./repos/svn可以查看svn目录的内容，但是现在我们通过http通信配置的svn都是可以在浏览器里直接访问的，所以这个命令在我们的应用中就有点多余了。 9）获得旧版本的快照： svn checkout -r 1729 # Checks out a new working copy at r1729 svn update -r 1729 # Updates an existing working copy to r1729 第一个命令是导出给定版本的快照，第二个是把本地副本变成给定版本的工作副本。 10）创建并导出分支 使用前面介绍过的svn copy命令创建一个分支，然后使用checkout导出一个分支的副本，这样你就可以在这个分支的副本上工作了。
11）和trunk保持同步 如果只在分支上开发，而分支又另外一些人在继续维护和开发，你们的差别肯定是越走越远，而且你的分支版本毕竟是从主版本走出去的，后续在主版本上的进一步开发和维护很可能你是非常需要的（比如主版本上bug的修复），因此经常和主版本保持一致是很重要的，而在和主版本的同步过程中，你的分支文件和主版本有冲突是非常正常的（很可能的情况是不同的人为不同的目的开发，冲突是必然的）。这是你只要自己修改就行，你的修改不会更改trunk版本，仅仅影响你自己的分支版本。
这里是一个和主版本同步的例子，myprj2是主版本的副本，在这里修改了b.txt并提交到svn服务器中。然后在branch-new（分支版本的副本）中进行了merge，注意这里没有发生任何冲突，如果发生冲突，解决方案和前面5）介绍的解决方案相同。 12）分支融合入主版本
我在分支节点修改了c.txt（假设我完成了分支节点的开发），并最终commit了。在主版本的副本里，我使用命令trunk：svn merge --reintegrate ^/branches/branch-new进行了融合。注意这里多使用了—reintegrate参数，因为把trunk融合入branch和把branch融入trunk是不同的，把trunk融入branch和正常的svn协同开发情况类似，在branch分支中添加别人的修改记录，可以使用svn proget svn:mergeinfo .来查看本地branch副本和那些版本号的trunk进行了融合，这里是保持了trunk版本号11和12的同步；而把branch融入trunk则不同，因为branch中之前已经加入了trunk的修改情况，所以再次融合回trunk时就会让svn服务器很困惑，所以必须加上—reintegrate参数，让svn服务器比对两个版本代码的不同（而不是使用补丁的方式）然后进行合并。另外这里使用了一个—dry-run参数，这个参数的意思是不进行实际的融合操作，只是看看如果运行融合可能会发生什么事情。 最后不要忘记把融合入trunk的branch版本删除掉
三、更多SVN 请参见SVN官方文档，另外可以多多使用svn help，如果对某一具体命令不清楚，比如add，可以使用svn help add进行查看。 四、来自互联网的一个SVN使用规范 在互联网上搜的，说的挺好，可以作为参考
先更新，再提交 SVN更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。 如果在修改的期间别人也更改了svn的对应文件，那么commit就可能会失败。如果别人和自 己更改的是同一个文件，那么update时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起 协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN合并错误导致代码有错。
多提交 每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改UI界面的时候，可以每完成一个 UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改 bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。 我个人感觉鼓励多提交的同时，也不应理解为在修改代码的时候要不断的提交，应该保证修改的代码可以编译运行，保证你提交之后，别人update之后别人的副本不能运行，确保你修改作为一个小的整体提交，个人观点
不要提交不能通过编译的代码 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有 安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够 在统一的环境中进行编译。
每次提交必须书写明晰的标注 在一个项目组中使用SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰 的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。
提交时注意不要提交本地自动生成的文件 例如eclipse中的.classpath文件，Windows生成的缩略图Thumbs.db，项目编译生成的临时 文件.obj, .class等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地 的环境冲突从而影响大家的工作。
不要提交自己不明白的代码 代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后 出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。 |
|
|
