我打算一口气讲完SVN的使用,所以,在看之前呢,请先深深的吸一口气(怎么听着像黑龙公主),当然吸完后还是要呼出来的。不要憋着了。
我们可能希望一来就直接操作。列出一堆命令。详细的命令参数等信息,我们都可以加入 --help 选项获取,下面不会详细介绍。除非必要。现在先看下面的例子:
$svn --help
usage: svn <subcommand> [options] [args]
Subversion command-line client, version 1.6.12.
Type 'svn help <subcommand>' for help on a specific subcommand.
Type 'svn --version' to see the program version and RA modules
or 'svn --version --quiet' to see just the version number.
Most subcommands take file and/or directory arguments, recursing
on the directories. If no arguments are supplied to such a
command, it recurses on the current directory (inclusive) by default.
Available subcommands:
add
blame (praise, annotate, ann)
cat
changelist (cl)
checkout (co)
cleanup
commit (ci)
copy (cp)
delete (del, remove, rm)
diff (di)
export
help (?, h)
import
info
list (ls)
lock
log
merge
mergeinfo
mkdir
move (mv, rename, ren)
propdel (pdel, pd)
propedit (pedit, pe)
propget (pget, pg)
proplist (plist, pl)
propset (pset, ps)
resolve
resolved
revert
status (stat, st)
switch (sw)
unlock
update (up)
Subversion is a tool for version control.
For additional information, see http://subversion.tigris.org/
好了,什么都出来了。一大堆信息。慢慢读吧。可是这样的方式,对我们使用SVN并无指导意义。什么时候用什么命令? 下面就来说一下SVN的基本使用,在此之前,还有两个重要的东西需要理解。
SVN 除了可以让你追溯历史,还有一个重要的功能,便是多人协作。我们要解决的问题不仅仅是可以从历史中恢复。还有如果多人同时修改一个文件,那么该以谁的为主呢?
所以在SVN中,我们有两种使用模式:
Lock-Modify-Unlock
简单的说就是,给需要修改的文件加锁,然后修改,然后解锁。
这是一个很好的办法。但是如果一个文件被锁住了,那么其他人就不能修改了。而此时如果是我在修改文件头,而你需要修改文件末尾的话,你也只能等我修改完。这样是很浪费你的时间的。所以我们又有另外一种模式。
Copy-Modify-Merge
这是一种很高级的模式,从库中拷贝一份,修改,然后根据拷贝的和库中的不同,在合并。为什么说高级呢,因为合并是一个很复杂的过程。很可能失败。但是这种方法却尽可能使大家不受影响。例如你和我同时修改一个文件,我改文件头,你改文件尾,然后一提交,就给合成一份了。不会互相打扰。事实上问题比这复杂的多。
好了,说了这么多废话。我们可以正式开始了。
虽然一般情况,我们是不用自己去创建一个SVN库的,现在为了说明流畅,我们从创建一个库开始。
$svnadmin create /var/idp/repos
于是我们创建了一个SVN库。到下面看看
$ls /var/idp/repos
conf db format hooks locks README.txt
我们的库就创建好了。这里不多说, svnadmin是一个高级命令,我们基本用不到。
导入需要管理的文件:
$svn import /home/madic/code file:///var/idp/repos -m "init code"
Adding /home/madic/code/signo
Adding /home/madic/code/signo/sigset.c
Adding (bin) /home/madic/code/signo/wait
Adding /home/madic/code/signo/wait.c
Committed revision 1.
这里版本变为1,初始版本为0。 每次对库的操作改变,都会产生一个新的版本。版本是我们追溯历史的一个索引。在版本管理中非常重要。当前库中最新的版本可以用HEAD表示。HEAD版也就是库中最新版本。
我们把 /home/madic/code 文件下的文件目录都导入了svn库,从此,他们就被时光机管理,数据永不丢失(当然你干掉时光机,数据还是会丢失的)。
注意 (bin) 表示这是一个二进制文件,非文本文件。
除了import 外,我们还可以用 svn add 添加文件。
使用list命令查看库中文件
$svn list file:///var/idp/repos
signo/
signo/sigset.c
signo/wait
signo/wait.c
现在,我们开始工作了。那么,就使用 CMC(Copy-Modify-Merge)模式吧。
如何创建一个Working Copy 呢?看:
$svn checkout file:///var/idp/repos /home/madic/code_svn
A /home/madic/code_svn/signo
A /home/madic/code_svn/signo/sigset.c
A /home/madic/code_svn/signo/wait
A /home/madic/code_svn/signo/wait.c
Checked out revision 1.
恭喜我们现在拥有一个Working Copy了,你就在这个WorkingCopy中折腾吧,只要不提交,那么对库来说就没有任何影响。就算你用了 rm 不小心删除了某个文件,不用着急。使用update便可以找回。
$svn update
svn update
Restored 'main.c'
At revision 1.
这里,我们删掉 main.c 然后到WC 下,执行 svn update 命令,就找回main.c了。
在Working Copy 目录中,Subversion如何知道文件的情况呢,其实这些都是 .svn的功劳。每个SVN管理的WC中,都会有一个隐藏的文件夹,.svn
$ls -la .svn
drwxr-xr-x 6 madic madic 4096 2011-07-26 11:00 .svn
如果不小心误删除,也可以用svn update恢复。
接下来,我们开始正常的编辑文件。编辑之前,已定要使用svn update 来确保你编辑的文件是最新的。如果不是最新的,那么这个文件就是 Out-of-date了,此时你的编辑就不能被提交到库中。编辑时,你不必使用svn的命令了。你可以用任何编辑器编辑文件。当你编辑完成后保存。
$svn status -q
M readme.txt
这个M表示此文件被修改了。于是我们需要把她提交到库,这样别人才能看到我修改的东西。
$svn commit -m "我修改了文件内容" readme.txt
svn commit -m "modify" readme.txt
Sending readme.txt
Transmitting file data .
Committed revision 8.
文件被提交,版本更新到8.
这样,我们就完成了一个最基本的SVN操作流程。也许如果没有什么大事,我们就到此结束了。难道还有什么问题吗?
上面提到,我们在修改的同时,可能别人也在修改。所以要尽量在每次修改的时候,保持我们的WC和库中的是同步的,也就是最新的。我们使用svn update来使自己的working copy是最新的。我们也可以用一个新的命令来看WC的状态。
$svn status -u -v readme.txt
M 8 8 madic readme.txt
M * 8 3 madic foo.c
我们看到readme.txt 目前是M(modify)状态,说明此文件被改了。当前版本和最新版本都是8 ,用户是madic。
而foo.c 多了个星号,这表明foo.c 已经out-of-date 了。也就是说,我们在修改的版本,已经不是最新的了。在我们修改的时候,已经有人提交了新的版本。
除了 M表示修改,还有 U表示更新,D表示删除,A 表示新增, C表示冲突。
有时候有两个MM,此时并非表示美眉,而是文件的内容和属性都被改变了。
同样UU表示属性和内容都更新了。
所以,在我们提交以后,并非就结束了,此时,我们需要查看一下状态。如果有文件处于C状态,那么说明我们遇到麻烦了。因为C表示冲突了,一定是某个人和我们在改同一个地方。
这时,最好的办法是直接找到和我们冲突的修改人。然后沟通吧。是你死还是我亡。冲突实际上是在svn update的时候发生的。由于我编辑的太久了,你已经提交了一个新版本,我提交的时候,提示 out-of-date了,于是我svn update,冲突出现:
$ svn update
Conflict discovered in 'readme.txt'.
Select: (p) postpone, (df) diff-full, (e) edit,
(mc) mine-conflict, (tc) theirs-conflict,
(s) show all options:
这时几个选择出现了,postpone 的意思是暂时推后处理,我可能要和那个和我冲突的家伙商量一番。 diff-full,则是比比看,到底什么地方冲突了。edit,修改冲突合并的文件。 mc,这个霸道,直接用我的。 tc , 底气不足,还是用别人修改的吧。我们一切三思而后行,所以选择了p,然后在看看文件目录下有什么。
多了三个文件:
readme.txt.mine readme.txt.r9 readme.txt readme.txt.r8
我们来说说这三个文件:readme.txt.mine 后最 mine是本地最新的。
readme.txt.r9 很明显,是版本9的,这个版本正式库中最新的版本。
readme.txt.r8 这个版本是库中最新的版本的前一版本。
我们来看一下,现在的readme.txt
$cat readme.txt
<<<<<<< .mine
hi
=======
hello
>>>>>>> .r9
很明显,我的版本中是hi ,而r9 的是hello。
好吧,我明白了。现在假设我们很明白,或者已经和发生冲突的文件的编辑同事商量好了。我们就要解决冲突了。
首先,上面说的三个文件,如果存在,我们就提交不了。
其次,需要选择一个解决方法。
$svn resolve --accepting working reademe.txt
svn resolve 是解决冲突的命令。解决的方法由--accepting 选项决定。
base 恢复到冲突前的一个版本。
mine-full 恢复到以我的修改为主的版本
their-full 恢复到库中最新版本
working 手动解决
所以,上面的那句命令其实还有问题,因为我们还没有手工修改文件。
于是我们打开readme.txt,去掉哪些冲突标识
<<<<<<< .mine
hi
=======
hello
>>>>>>> .r9
修改为
No hi no hello
然后保存readme.txt
在使用
$svn resolve --accepting working reademe.txt
注意,这一步以后,并没有真正完成冲突解决。
$svn commit -m "conflict resole"
Sending readme.txt
Transmitting file data .
Committed revision 10.
这次提交OK。冲突至此解决。
有时候,我们编写到一半发现有人提交了更新或者是越写越乱,我们想放弃这次编辑,恢复到上一个版本,当然,我们可以直接rm掉,然后update,我们也可以这样:
$svn revert readme.txt
Reverted 'readme.txt'
问题解决以后,请使用svn status 查看一下状态,是否正常了。
$svn status -vu readme.txt
10 10 yinshaoxin readme.txt
Status against revision: 10
没有什么M,C,* ,D, ? 这些,说明状态正常。
对于我们操作的这些,我们可以通过历史svn log来查看状态。
$svn log
r9 | yinshaoxin | 2011-07-26 13:39:12 +0800 (Tue, 26 Jul 2011) | 1 line
shaoxin
------------------------------------------------------------------------
r8 | madic | 2011-07-26 11:12:47 +0800 (Tue, 26 Jul 2011) | 1 line
modify
------------------------------------------------------------------------
r7 | madic | 2011-07-26 09:35:51 +0800 (Tue, 26 Jul 2011) | 1 line
code
------------------------------------------------------------------------
r6 | madic | 2011-07-20 15:43:52 +0800 (Wed, 20 Jul 2011) | 1 line
pa
------------------------------------------------------------------------
r5 | madic | 2011-07-20 15:42:19 +0800 (Wed, 20 Jul 2011) | 1 line
p
------------------------------------------------------------------------
r4 | madic | 2011-07-20 10:40:03 +0800 (Wed, 20 Jul 2011) | 1 line
dir
------------------------------------------------------------------------
r3 | madic | 2011-07-19 14:01:49 +0800 (Tue, 19 Jul 2011) | 1 line
keywords
------------------------------------------------------------------------
r2 | madic | 2011-07-19 13:58:24 +0800 (Tue, 19 Jul 2011) | 1 line
new test
------------------------------------------------------------------------
r1 | madic | 2011-07-15 16:56:05 +0800 (Fri, 15 Jul 2011) | 1 line
ci chage
------------------------------------------------------------------------
天哪,所有的svn日志都显示出来了。我们可以使用r来确定一个范围。
这就是时光机的历史查看了。来吧,想看哪一个版本的。
$svn log -r 5:9
------------------------------------------------------------------------
r5 | madic | 2011-07-20 15:42:19 +0800 (Wed, 20 Jul 2011) | 1 line
p
------------------------------------------------------------------------
r6 | madic | 2011-07-20 15:43:52 +0800 (Wed, 20 Jul 2011) | 1 line
pa
------------------------------------------------------------------------
r7 | madic | 2011-07-26 09:35:51 +0800 (Tue, 26 Jul 2011) | 1 line
code
------------------------------------------------------------------------
r8 | madic | 2011-07-26 11:12:47 +0800 (Tue, 26 Jul 2011) | 1 line
modify
------------------------------------------------------------------------
r9 | yinshaoxin | 2011-07-26 13:39:12 +0800 (Tue, 26 Jul 2011) | 1 line
shaoxin
------------------------------------------------------------------------
注意 -r 5:9 和 -r 9:5 是不同的顺序显示。
当然也可以指定一个文件的版本日志。
使用log注意,当你提交一个版本后,log并看不到这个日志。
因为 commit 和 update是独立的。commit并不更新本地版本。我们只有使用 update以后,在使用log则可以看到。
还有,如果你使用svn log 不指定路径的话,那么默认的是当前的目录。这样,对于其他目录的log,我们只有一条空日志。
$-------------------------------------------
最后不要像我一样,日志都是乱七八糟,请重视日志,因为在以后查找问题梳理版本变化的时候,会对你有很大帮助。
好了,从现在开始,你已经基本掌握SVN的用法了。如果具体命令参数不会用,请使用 help 。
如果你想了解的更多一点,那么我们继续看下一章。
分享到:
相关推荐
### SVN学习笔记 #### 版本控制的重要性及概念解析 版本控制在软件开发过程中扮演着极其重要的角色。尤其是在多人协作的环境下,版本控制系统能够有效帮助团队成员管理代码、文档和其他重要资源的不同版本,确保每...
- 学习笔记通常包含个人理解和实践总结,可能涵盖一些实用技巧和常见问题解决方案。 通过以上内容,你将能够掌握SVN的基本操作和使用策略,更好地融入团队开发环境中。在实际工作中,结合具体的项目需求和团队协作...
**我的SVN学习笔记(原创)** 在信息技术领域,版本控制系统是不可或缺的工具之一,它帮助开发者跟踪和管理代码的变化,使得多人协作变得有序而高效。Subversion(简称SVN)就是这样的一个开源版本控制系统,它允许...
在学习笔记中还提到了一些可能遇到的问题及解决方法,比如在安装配置过程中可能会遇到的权限问题、网络问题或者配置错误等,这些内容虽然没有详细展开,但它们对于理解和使用SVN来说是不可或缺的一部分。 总体而言...
**文件名称列表:** "svn学习笔记.doc" 这是一个文档文件,很可能是博主详细记录的安装步骤和经验总结,可能包含了截图、命令行示例以及遇到问题的解决方案。 **详细知识点:** 1. **Subversion(svn)基础:** ...
以下是对"SVN笔记学习"内容的详细解读: 1. **Linux下SVN的搭建** - **安装SVN**: 在Linux系统中,通常通过包管理器来安装SVN,如在Ubuntu或Debian上使用`apt-get install subversion`,在CentOS或Fedora上使用`...
通过本文的学习,我们不仅深入了解了SVN的基本概念和原理,还掌握了SVN的实际应用技巧。无论是对于个人开发者还是大型软件团队,熟练运用SVN都是非常必要的。希望本文能够帮助读者更好地理解SVN的核心价值,并将其...
【SVN 学习笔记】 SVN,全称Subversion,是一种版本控制系统,用于管理和跟踪文件及目录在不同时间的变化,使得多人协作开发时能够有效管理代码版本,防止代码冲突,回溯历史版本,以及方便地进行代码审查。这篇...
SVN与CVS一样,是一个跨平台的软件,支持大多数常见的操作系统。作为一个开源的版本控制系统,Subversion 管理着随时间改变的数据。这些数据放置在一个中央资料档案库 (repository) 中。 这个档案库很像一个普通的...
SVN(Subversion)是版本控制系统中的一种,用于管理和跟踪软件项目中的文件和目录变更。作为一款开源的、跨平台的开发工具,它在协同开发环境中扮演着至关重要的角色,帮助团队成员有效地共享代码,同时保持项目的...
总之,通过"svn搭建笔记.zip"这份资源,你可以系统地学习如何从零开始搭建SVN服务器,逐步掌握版本控制的核心概念和操作技巧,这对于任何软件开发者而言都是一项基础且必要的技能。记得在实践中多加练习,理论结合...
《我的cvs2svn笔记》是一份详细的指南,旨在帮助用户在Windows环境下将CVS(Concurrent Versions System)版本库转换为SVN(Subversion)版本库。CVS是一种广泛使用的源代码控制系统,而SVN则因其先进的特性,如分支...
Maven 和 SVN 是软件开发中常用的两个工具,它们...这些笔记对于初学者来说是一份宝贵的资源,帮助他们快速理解和掌握Maven和SVN的安装与基本使用。通过学习这些内容,开发者可以更有效地进行协作开发,提高工作效率。
集中式版本控制系统以CVS和SVN为代表,它们使用一个单一集中管理的服务器来保存所有文件的修订版本,所有开发者从该服务器下载最新版本,进行开发并提交更改。CVS是最早的开源版本控制系统之一,它可以跨平台使用,...
在“svn技术总结本人自己学习笔记.zip”这个压缩包中,我们可以期待找到关于SVN的基本概念、安装配置、日常操作、冲突解决以及高级特性的学习记录。 首先,SVN的核心概念包括仓库(Repository)、工作副本(Working...