精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (4)
|
|
---|---|
作者 | 正文 |
发表时间:2009-07-13
最后修改:2009-07-30
SVN简明课程
1. 版本控制介绍
1.1. 什么是版本控制
版本控制系统用于保存编写开发应用程序时的文档的各个修订版(revision)。 版本控制也称作Revision Control System(RCS)。 名词解释:
1.2. 使用版本控制的好处
对团队和个人都有好处:
1.3. 常见的版本控制系统
2. Subversion介绍
Subversion是新一代的版本控制工具,正逐步替代CVS。 资源:
3. Subversion基本使用
3.1. Subversion安装
Subversion是典型的C/S模式应用程序。 Windows环境下的安装包:http://subversion.tigris.org/files/documents/15/41687/svn-1.4.6-setup.exe 安装过程很简单,图形界面,默认选择即可。 输入svn命令查看安装是否成功:
svn --version
svn命令是subversion程序的客户端 svnserver命令可以启动svn服务器,用于搭建简易的svn服务器环境 见:http://www.easymorse.com/bbs/viewthread.php?tid=95&extra=page%3D1
3.2. 服务器端
以下是搭建简易的服务器端环境的做法,正式一般配合apache通过http访问。
3.2.1. 创建版本库
创建服务器端版本库,相当于DBMS创建数据库示例。 命令行:
svnadmin create file_path/repo_name
3.2.2. 启动服务器
svnserve.exe -d -r file_path
访问该版本库的url:svn//localhost/repo_name
3.3. 客户端
3.3.1. 初始导入(import)
通过命令行导入:
svn import -m "init import" http://10.0.0.6/svn/teaching/
该命令可将当前路径下文件导入到版本库中。
3.3.2. 检出(checkout)
通过命令行检入:
svn co http://hibernate3demo.googlecode.com/svn/tags/helloworld_r1
或者:
svn checkout http://hibernate3demo.googlecode.com/svn/tags/helloworld_r1
或者:通过第三方图形工具的检出,比如tortoiseSVN(http://tortoisesvn.tigris.org/) 将svn服务器的最新修订版下载到本地成为本地工作拷贝。
3.3.3. 保持更新(update)
命令行:
svn update
或者
svn up
或者通过tortoiseSVN 或者通过eclipse插件,subclipse(http://subclipse.tigris.org/),在线安装:http://subclipse.tigris.org/update_1.2.x/ 用svn服务器的最新修订版更新本地工作拷贝。 多人合作时:
3.3.4. 添加(add)
命令行:
svn add file_path
或者通过tortoiseSVN,eclipse插件。 告知svn服务器,添加目录和/或文件到服务器上,这个操作类似SQL的insert,但是并没有真的操作,直到commit。
3.3.5. 提交改动
相当于通用概念:检入(checkin)。 命令行:
svn commit
或者:
svn ci
或者通过tortoiseSVN,eclipse插件。 提交本地工作拷贝的所有改动,而且是原子性的。 要求:一般要注明修改的原因
svn ci -m "修改bug #224"
要求:提交之前要做更新
svn up svn ci -m "修改bug #224"
3.3.6. 还原改动
对应提交(commit),要有类似回滚(rollback)的操作。
svn revert
或者通过tortoiseSVN,eclipse插件。 这个操作对开发人员十分有用,在改动被人很多代码后可以“一键恢复”。
3.3.7. “还原”已提交的改动
revert只适合未提交的情况。 如果已经提交,发现问题,要回退到之前的修订版。 首先需要:
svn up
让本地工作拷贝更新到最新状态。 然后:
svn log your_file_path
查看文件日志,这时候提交时填写的说明信息就派上用场了。 查看两个修订版之间的不同:
svn diff -r 旧修订版序号:新修订版序号 your_file_path
或者通过tortoiseSVN,eclipse插件。 决定用哪个旧的修订版号后,用旧的修订版号文件覆盖新的修订版号文件。
svn merge -r 新修订版序号:旧修订版序号 your_file_path
还需要:
svn commit -m "恢复到某修订版(某修订版作废)"
或者通过tortoiseSVN,eclipse插件。 这个还原是所谓的,不是用旧的版本号替代,而是将旧文件覆盖新文件。
3.3.8. 拷贝文件和目录
命令行:
svn copy path/file_name newpath/new_file_name svn commit -m "xxxx"
或者:
svn cp path/file_name newpath/new_file_name svn commit -m "xxxx"
或者:利用windows的资源管理器/unix的cp命令 或者通过tortoiseSVN,eclipse插件。 svn的copy,是很重要的工具,版本分支和标签等概念都通过它实现。 svn的copy,是廉价的拷贝。
3.3.9. 重命名目录/文件
命令行:
svn move file_name new_file_name
或者:
svn mv file_name new_file_name
3.3.10. 处理合并冲突
svn默认不对文件加锁。 如果不同人编辑了同一个文件的不同部分,提交时会自动合并。 如果不同人编辑了同一个文件的同一部分,后提交者会报告合并冲突。 解决方法(人工仲裁):
3.3.11. 删除文件
将本地工作拷贝删除。 命令行:
svn delete file_path
或者:
svn del file_path
4. Subversion高级内容
4.1. 文件锁
一般用于二进制内容,因为无法合并。 如果某个文件加锁,其他用户的本地工作拷贝(更新后)将是只读的。 当该用户提交后,其他用户的本地工作拷贝(更新后)才可以写操作。 其他用户可以“撬锁”,然后进行写操作。 高级配置可以配置“撬锁”权限,使不是什么人都可以“撬锁”。
4.2. 版本库创建策略
单一的版本库保存一个项目。 单一的版本库保存多个项目。 多个版本库。
4.3. 使用标签和分支
在svn中标签和分支都源于copy命令。 3个约定俗成的目录:
发布分支:
svn cp -m "创建用于实现radio标签的分支" https://easymorse-simpletag.googlecode.com/svn/branches/simpletag_select_1 https://easymorse-simpletag.googlecode.com/svn/branches/simpletag_select_2
切换分支:
svn switch https://easymorse-simpletag.googlecode.com/svn/branches/simpletag_select_2
合并分支需要两个步骤: 合并操作
svn merge -r 33:HEAD https://easymorse-simpletag.googlecode.com/svn/branches/simpletag_select_2
或者:
svn merge https://easymorse-simpletag.googlecode.com/svn/trunk/simpletag@HEAD https://easymorse-simpletag.googlecode.com/svn/branches/simpletag_select_1@HEAD
提交。
5. 未讲到的内容
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2009-07-14
windows下用VisualSVN Server建立apache+SVN服务器会简单很多
VisualSVN Server可从 http://www.visualsvn.com/server/download/ 下载 感觉用VisualSVN Server进行权限管理很方便,安装卸载也很容易,又是免费的,推荐尝试使用。 |
|
返回顶楼 | |
发表时间:2009-07-16
感觉还是用apache搭配上好用
独立svn总是看着那个打开的dos窗口觉得别扭 |
|
返回顶楼 | |
发表时间:2009-07-17
holmes1214 写道 感觉还是用apache搭配上好用
独立svn总是看着那个打开的dos窗口觉得别扭 用什么东西都是个习惯. |
|
返回顶楼 | |
发表时间:2009-07-17
感觉一般 不过认识 给点鼓励 哈哈
|
|
返回顶楼 | |
发表时间:2010-01-25
本人在使用SVN时遇到一个问题: repository 的trunk为trunk0. 1. 创建trunk1版本,Local copy 到本地,然后更改,更改好后,但由于没到该版本的发布时间,而且UAT尚没完成,只能在本地上保存副本; 2. 这时有一个新的需求,该需求要等到下一个release才能发布,所以需要check out trunk0创建新的trunk2先做改动,以保持工作进度; 3. trunk1的所有测试已经完成,可以发布了;于是将trunk1 check in到repository;此时truck的版本为trunk1; 4. trunk2也完成了,但这时trunk2不包含trunk1的更新,就是说trunk1,trunk2来自trunk0,但由于发布时间不同,导致trunk2内容缺失; 5. 为保证工作的完整性,我把trunk1的所有改动手动添加到trunk2里头;trunk2经过测试后,check in到repository;或者,把trunk1 copy到本地,把trunk2的更新放到trunk1上,再update到trunk3上;这两种方法的工作量都可能很大; 6. 如果trunk1出现了问题,或者还没到release2的发布时间时,trunk1又有新的需求,这时就能在trunk1的基础上出现了后续支线,而trunk2则永远在trunk0的基础上创建的,而不是在最新的基础上创建的。这样支线就会变得混乱......
trunk作为一条主线,保证了version在工作进程的流水进度;但由于trunk2的版本不是基于trunk1的基础上的,而它们二者都是基础trunk0的,于是,工作流水线上出现了从trunk0开始的trunk1 和trunk2的分支;如果按照默认的规则,服务器端配置了branches和tag等工作标签,分支就会变得很明显。
如何才能保证trunk0 -> trunk1 -> trunk2 -> trunk3一条线呢?
问题支线: trunk0 | -------- trunk1 --- branches1 ----- tag 1 | | | trunk 1.0 --- branches1.0 ----- tag 1.0 | | | trunk 1.1 --- branches1.1 ----- tag 1.1 | | -------- trunk2 --- branches2 ----- tag 2
需求支线: trunk 0 | trunk 1 | trunk 1.0 | trunk 1.1 | trunk 2 | trunk 3 | ..........
|
|
返回顶楼 | |
浏览 41042 次