一、如果开发过程中没有SVN
软件研发过程中,任意一个项目都是由一个团队完成的,而不能依靠单一个体完成。
在团队开发过程中,资料数据的共享与同步将成为开发过程中比较突出的问题。
原始开发管理模式(COPY模式)
缺点:
代码管理混乱
备份多个版本,占用磁盘空间大
解决代码冲突困难
容易引发BUG
难于追溯问题代码的修改人和修改时间
难于恢复至以前正确版本
无法进行权限控制
项目版本发布困难
为保障团队开发过程中人员沟通各方面成本的降低,必须使用一种有效的方式减少沟通环节,提高开发效率,对资源的共享进行管理。
现阶段的开发管理模式(Tools模式)
相关概念:
服务器 server 专用的硬件服务器
仓库 repository 专用于某个项目的磁盘空间,位于硬件服务器中
检出 checkout 一次性工作,下载代码并完成与服务器间的关联
上传/提交 commit 多次工作
更新 update 多次工作
记录日志 logger 记录操作相关的信息,包括动作,用户,时间,信息
版本号码 version 记录文件被操作的次数,即版本数
作为一个管理共享资源的工具必须具备以下几点:
1. 能够记录日常事务中所有的文件的新建,编译,删除
2. 能够记录文件的操作人,操作时间,操作描述信息
3. 对于同一个文件,能够提供更多的历史版本供适用者参考
4. 对于不同的文件,能够提供更高的管理权限,限制用户的使用能力
5. 对于不同的项目/Case,能够提供更多的空间管理模式
6. 对于不同的用户,提供远端访问支持,使用户更快捷进行资源共享
二、什么是版本控制?
版本控制(Revision control)是维护工程蓝图的标准做法,能追踪工程蓝图从诞生到定案的过程。是一种记录多个文件内容变化,以便将来查阅特定版本修订情况的系统。
三、SVN是什么?
SVN(subversion)是近年来崛起的版本管理工具,是cvs的接班人。目前,绝大多数开源软件都使用SVN作为代码版本管理软件。不要狭义的理解只服务于软件研发,很多公司都适用SVN管理整个公司的文档。
四、SVN的作用?
针对软件研发企业的软件生产过程而言,SVN用于管理整个开发过程中的源码,进行版本控制。
五、SVN的日常使用
5.1 浏览仓库中的资源信息
5.2 导入导出
Export :导出项目 ,和checkout区别 (checkout检出后文件,含有.svn隐藏文件夹, 会和SVN仓库交互, export导出,没有.svn隐藏文件夹)。
import 将本地资源导入到svn 服务器。
5.3 修改提交
5.3.1 CheckOut
检出项目,复制项目的副本到本地。
5.3.2 add
在检出的目录中添加文件
5.3.3 commit
当检出目录或子目录中内容有修改, 提交Commit 提交本地修改至svn服务器
5.3.4 update
更新仓库的文件到本地:更新到最新版本/跟新到指定版本
5.3.5 delete
删除版本库文件
5.3.6 恢复
在检出目录或子目录操作会记录操作日志,提交前可以回滚操作。
5.4 冲突处理
什么是冲突?
冲突就是在同一个版本基础之上,多个人对该文件修改了修改,其中一个人将文件提交到SVN,这时,该文件已经是新的版本,但是,其他人的本地还是旧的版本,
这时,其他人并不知道该文件已经有了新的版本,执行提交操作,这时就产生了冲突。
解决冲突的核心思想:为了避免冲突,要在最新的版本之上修改(也就是说修改之前先更新),再提交。
如果我更新了之后,在编写代码的同时别人将该文件再次更新(我不可能时时刻刻都查看更新),这时直接提交会造成冲突,正确的做法是:提交之前将该文件先执行与资源库同步操作,先将冲突解决掉再提交代码。
接下来就需要讨论下个话题了,如何解决冲突?
首先要先明确,解决冲突是不能通过工具自动完成的,必须人工完成,当然了,可以借助工具辅助完成。
在我看来解决冲突有三种办法:第一种就是改自己的代码,通过小部分改动自己代码,而不会对程序产生严重影响的情况下可以通过改自己代码解决。第二种就是和冲突代码作者协商解决,寻找完美代码共存办法。第三种就是无法共存,只能同步本地代码,在别人提交代码的基础上再来编写代码。