TortoiseSVN客户端常用命令详解解析文档格式.docx
《TortoiseSVN客户端常用命令详解解析文档格式.docx》由会员分享，可在线阅读，更多相关《TortoiseSVN客户端常用命令详解解析文档格式.docx（34页珍藏版）》请在冰豆网上搜索。
Log内容包括：
修改了哪些东西及为什么做这些修改（what+why）
强制必须录入log:
property中设置录入log最小长度，此时commit必须录入log,否则不允许提交.
设置录入log最小长度页面：
4、add
将要添加的文件或者目录拷贝到WC下，
然后在该文件或目录上单击右键，TortoiseSVN->
Add，点OK。
如果添加了不止一个文件或目录，
则鼠标不要在WC中点中任何文件，
然后单击右键，TortoiseSVN->
Add，
就可以添加多个文件或目录。
这时文件的状态图标会发生如下变化：
Add命令只是告诉本地的WC将该文件纳入版本管理，
并没有将这个改变提交到服务器端，
在F:
\Project1下单击右键，SVNCommit...，
将你所做的修改提交到Repository。
5、modify
用文本编辑器或IDE对文件修改后，
文件的状态图标会变化，
然后单击右键，SVNCommit...即可提交修改。
6、revert
（1）、放弃未提交的修改，
单击右键，TortoiseSVN->
Revert，
本地的WC中的文件和目录会恢复到修改前的状态。
（2）、回复到之前某个revision状态：
a、在本地WC中单击右键，TortoiseSVN->
UpdatetoRevision...，
然后输入你想要回复到的Revision号
点OK按钮。
此时仅仅是WC中回复到特定版本，对Repository没有任何影响。
b、把Repository回复到某个revision状态方法：
方法一：
先执行Update命令将WorkingCopy更新到最新的Revision，
然后在WorkingCopy中单击右键，
TortoiseSVN->
ShowLog，
弹出的LogMessages窗口中会显示该Repository的所有Revision，
选中最新的Revision，之后按住Shift键，
再单击你想回复到的Revision+1的那个Revision
（比如Repository的最新Revision是79，
你想将Repository的状态回复到Revision60，
那么就选中Revision70，再按住Shift键，
选中Revision61，
就是说选中Revision61到Revision79之间的所有Revision）。
然后在选中的Revision上单击右键，
选中“Revertchangesfromtheserevision”。
再点Yes按钮，就可以将WC的状态回复到目标Revision60。
注意：
此时只是WC回复到目标Revision，之后应该用Commit提交修改，
这样Repository最新状态就与WC的状态一致，都为Revision60。
方法二：
采取大版本号向小版本号merge的方式，进行回滚
保证我们拿到的是最新代码，TortoiseSVN右键merge,如果我们最新版本为79，要回滚到60，如下图，“From”的URL和“to”的URL均了录入要回复的文件在版本库的存放地址
点“merge”,然后commit即可。
7、delete
删除文件时，选中要删除的文件或目录，
Delete
然后提交修改。
注意千万不要用windows自己的“删除”或者“Delete”键来删除文件，否则将无法提交你的修改。
这一点对目录的删除来说尤为重要。
因为每个目录里有个.svn隐藏目录，存放目录下文件的信息，使用操作系统命令delete/move时，.svn还指向原来的位置，所作操作不受SVN控制。
8、move
移动方法：
（1）、选择你要移动的文件或目录
（2）、拖拽（right-drag）他们到新的工作副本下，
（3）、松开鼠标右键
（4）、在弹出菜单选择上下文菜单→SVN移动文件。
原理同上。
9、Branche/Tag
操作方法：
创建分支非常简单，只需在需要创建分支的工作目录上，使用TortoiseSVN→Branch/Tag命令，在"
ToURL"
项指定待创建的分支url即可
实现本质：
subversion对分支和标签是通过复制一份最新的版本库的快照来实现的。
一般情况下，tag，是用来做一个milestone的，不管是不是release，都是一个可用的版本。
这里应该是只读的,更多的是一个显示用的，给人一个可读（readable）的标记；
branch，是用来做并行开发的，这里的并行是指和trunk进行比较。
分支与标签的区别：
在实现上，branch和tag，对于svn都是使用copy实现的，所以他们在默认的权限上和一般的目录没有区别。
至于何时用tag，何时用branch，完全由人主观的根据规范和需要来选择，而不是强制的（比如cvs），一个不去做任何的修改的分支就是版本库某一时刻的一个快照，相当于为某一个版本做了一个标签
Branch和Tag都是拷贝指向原始文件的链接，当你对拷贝做修改时，记录为相对原始文件的修改，称为延迟拷贝，效率高且几乎不占用空间。
Tag：
版本号是个好东西，但是我们更倾向于记住像第二预览发布版这样的名字，而不是V01这样的数字，标签是用来做这件事情的。
版本控制系统可以让你给某一个时刻的一组文件或者一些目录或者整个项目分配一个名字。
如果你给某几个文件分配标签“第二发布预览版”，以后就能使用这个标签签出它们。
标签是一种很好地跟中项目代码开发过程中发生的重要事件的方式。
分支合并：
使用TortoiseSVN→Merge命令，在“From:
（startURLandrevisionoftherangetomerge）”中选择希望合并的目录（如：
trunk），并指定希望合并的开始revision编号，在“To:
（endURLandrevisionoftherangetomerge）”中选择结束revision编号。
然后点击“merge”完成合并操作，剩下的工作就是编辑冲突了。
当然运气好的话是不需要这个过程滴。
值得注意的是，“From:
”和“To:
”中的URL通常是相同的，切记不要与创建分支时的含义混淆
10、getlock/releaselock
选择工作副本中你想要获取锁定的文件，然后选择命令TortoiseSVN--->
Getlock…
出现一个对话框，允许你输入注释，这样别人知道你为什么锁定这个文件。
注释是可选的，
并且只用于基于Subversion的库。
选择需要锁定的文件在复选框打勾，点击“确定”按钮
锁定选择的文件：
出现一个对话框，输入正确的用户名和密码即可向版本库提交你想锁定文件的信息。
锁定文件成功！
返回信息！
”Lockedbyadmin”表示文件已被admin用户锁
定；
”alpay_payto.php”表示锁定文件的名称。
点击”OK”按钮确定锁定文件成功。
释放锁定（取消锁定）
选择工作副本中你想要取消锁定的文件，然后选择命令TortoiseSVN--->
Releaselock…
之后操作同getlock。
当被锁定文件commit后，会自动解锁，无需再去解锁；
如果commit后还需上锁，则在commit时可选择：
“keeplock”
强制锁定：
设置对象文件svn:
needs-lock这个属性，update后强制文件的属性为只读，只有lock之后，才能对文件进行修改操作，commit-releaselock之后，又自动变成只读。
具体做法：
先将a.jpg文件拷贝到WC中，然后在该文件上单击右键，
Add，告诉Subversion要将该文件纳入版本控制，
接着在该文件上单击右键并选中属性，
在弹出的属性对话框中选中Edit键，在propertyname中如下图。
在下拉框中选中“svn:
needs-lock”，
并在下面的文本框中填入“*”
（其实这里填什么都无所谓，只要文件有“svn:
needs-lock”附加属性就行），
之后点Set按钮，“svn:
needs-lock”附加属性就设置好了。
然后执行Commit命令提交修改。
这时当其他人执行Update时，
a.jpg就会添加到他们的WC中，
并且文件的附加属性也会随文件一起被得到。
可以看到a.jpg此时的图标就是灰色的，
文件的Windows属性也是只读的
11、cleanup
SVN本地更新时，由于一些操作中断更新，如磁盘空间不够，用户取消，
可能会造成本地文件被锁定的情况。
一般出现这种情况的解决方法：
（1）、可以使用SVNcleanup来清除锁定。
（2）、如果不是本目录锁定，系统提示上一层目录锁定，需要到上一层或者根目录中清除。
（3）.如果在根目录下都无法clean的话，一般采取的方法是另外找一个目录重新checkout。
但有时SVN目录下可能有一些自己本地修改的文件，还未提交到SVN服务器，这时重新checkout需要注意本地文件的备份，并且不要强制覆盖服务器上其它人修改的内容。
（4）、如果觉得第３种很麻烦，可以考虑这样的方法。
其实SVN加锁会在.SVN（隐藏文件）中生成一个名字叫lock的文件（无后缀），查找所有的手工删除。
然后再尝试更新，系统可能会提示某个.base文件无法访问。
找到它，把相关的文件或其所在的目录删除，重新update。
工作量就小多了。
12、export
集成测试或项目上线需要版本时，使用export而不用checkout，export得到干净的目录与文件，不带版本控制因素。
13、Checkformodifications
同服务器上的项目版本进行比较，并可做相应的修改。
14、Showlog
查看版本日志及不同版本间相互比较
15、RevisionGraph
版本示意图
16、Repo-Browser
查看当前版本库，这是TortoiseSVN查看版本库的入口，通过这个菜单项，我们就可以进入配置库的资源管理器，然后就可以对配置库的文件夹进行各种管理，相当于我们打开我的电脑进行文件管理一样
17、Rename
SVN支持文件改名,点击Rename,弹出文件名称输入框,输入新的文件名称,点击确定,再把修改提交,即可完成文件改名。
18、switch与relocate
版本库转移，当我们版本库发生转移的时候就需要用到这个功能。
例如我原先的版本库是建在U盘上的，现在转移到（复制整个配置库文件夹）开发服务器上，使用https代替文件系统的访问。
因此就需要将原来的工作拷贝的目标版本库重新定位到开发服务器上。
relocate与switch的区别：
（1）、如果WC反应相同的版本库目录，但是版本库本身位置改变了，使用relocate;
（2）、如果WC需要反应一个版本库的新目录，素要switch。
19、switch与svnupdate比较：
svnswitch和svnupdate的输出很像，switch命令只是update命令的一个超集。
当你运行svnupdate时，会告诉版本库比较两个目录树，版本库这样做，并且返回给客户区别的描述，svnswitch和svnupdate两个命令唯一区别就是update会一直比较同一路径。
也就是了，如果你的工作拷贝是/calc/trunk的一个镜像，当运行svnupdate时会自动地比较你的工作拷贝的/calc/trunk与HEAD版本的/calc/trunk。
如果你使用svnswitch跳转工作拷贝到分支，则会比较你的工作拷贝的/calc/trunk与相应分支目录的HEAD版本。
换句话说，一个更新通过时间移动你的工作拷贝，一个转换通过时间和空间移动工作拷贝。
因为svnswitch是svnupdate的一个变种，具有相同的行为，当新的数据到达时，任何工作拷贝的已经完成的本地修改会被保存，这里允许你作各种聪明的把戏
20、diff：
（下面是针对同一个文件而言）
原本错误地理解了diff的意思是比较本地的文件与服务器的相应文件有什么不同，但实际意思并非这样。
更准确地说这条语句的意思是比较一个文件中你修改过的部分与服务器的相应文件相应部分有什么不同，对于那些没有修改过的地方（同一文件中）不同也不会比较，当然可以先up一下再svndiff
这样就保证了本地文件与服务器的相应文件的所有不同的地方全都显示出来了，当然冲突情况除外.
21、dryrun
合并前看看结果会是什么样的.一个简单的办法就是运行dryrun先看看，并不真实的将结果写入到工作副本中.它只是显示在合并过程中输出的执行结果状态码.比较'
高级'
的预言合并,当运行svndiff可能会给出太多的详细日志.
22、create/applypatch
（1）、使用createpatch可以生成一个或者多个修改过的文件和当前版本差异的patch（支持目录树）
通常情况下，createpatch将修改保存为.patch或.diff文件
可以将.patch或.diff文件的内容复制出来，发给需要审查的人
.patch或.diff文件中记录了发生这个patch的版本号以及具体修改的内容
针对某个文件或某几个文件的若干种修改，可以生成多个.patch或.diff文件
（2）、applypatch
可以将.patch或.diff文件应用到对应版本的项目，就像打补丁一样
同一个项目/文件夹下，可以选择应用需要的patch
通常来说，应用一个patch时文件版本和生成这个patch时文件的版本是一致的；
如果不一致，也可以强制应用，svn会自动进行diff（这时候需要手动合并）
linux下，可以使用系统的patch命令来应用patch，eg:
patch-p0<
xxx.patch
（3）、使用
暂时不需要提交或不允许提交的修改，可以选择createpatch来保存修改的内容
选择createpatch来保存修改的内容并且提交patch，通过审查后，（在服务器端）应用patch
当一个功能有多种解决方案时，可以生成多个patch，（提交后）分别经过测试，再决定应用哪个patch
多个功能分别需要改同一个文件的不同地方（即没有同一行），可以做成多个patch，应用patch的顺序没有要求（在linux下应用也一样成功，只是会生成多个.orig文件）
多个连续性的功能，他们修改的文件都与一个base作patch，例：
p1在v1的基础上开发v2，生成v2和v1之间的patch1；
p2在v2的基础上开发v3，生成v3和v1之间的patch2，这样只要应用patch2也就应用了patch1。
（4）、带来的问题
一个较早的patch，在经过多轮提交后，如果想再要应用，需要严格的diff
如果两个patch分别改了同一行代码，应用第一个patch后要再应用第二个patch时，仍然需要diff。
如果在linux下，会产生冲突，生成.orig和.rej两个文件（此时仍然需要手动进行比较合并）
第3部分提到的连续性，要准确的预见到，比较困难
第3部分提到的多个连续的功能，后做的功能的某个文件更新了先做的功能的内容，但先做的功能可能还涉及到其他文件，容易造成漏更新文件的情况
23、subversion的版本控制模型
当你用subversion进行版本控制时，
Subversion会记录你对Repository进行的每一次修改（包括添加，修改，删除等等），
每修改一次Repository都会产生一个新的Revision（修订版本号），
不同的Revision代表了不同时刻Repository的状态，
因此我们可以用这个Revision回朔任意时刻Repository的状态，
就像时间机器一样，也就是说某一Revision
就是Repository在某一时刻的一个“快照”。
Revision不是针对某一个文件或者目录，
而是针对整个Repository而言的。
每修改一次Repository，Revision都会增加1。
Subversion的版本控制模型是一种叫做Copy-Modify-Merge
（拷贝-修改-合并）的模型。
考虑这种情况：
张三和李四是公司同一个部门的同事，
他们共同维护一个文本文件a.txt，
并且对该文件进行版本控制，
因此他们把这个文件放到一个Repository上共同维护该文件。
周一上午9点，张三和李四同时想对a.txt文件进行修改，
于是他们同时从Repository上取得该文件的最新版本（Revision10），
然后进行修改。
过了三分钟，张三首先完成了修改，
他在该文件的第五行修改了一个单词的拼写（将Typo改为Type），
于是张三对修改后的文件执行Commit命令，
将修改提交到服务器端的Repository中。
这时Repository的Revision变为11。
六分钟过后，李四也完成了他的修改，
他修改了该文件第十行上的一个单词拼写（将He改为She），
于是他也对修改后的文件执行Commit命令，
这时Subversion在提交修改时会发现，
李四修改的文件是Revision10的a.txt文件，
而不是最新的Revision11的a.txt文件。
于是，Subversion提示李四在提交修改前，
应该先将WorkingCopy更新到最新版本，
李四执行Update命令将WorkingCopy更新到Revision11，
这时Subversion会提示已经完成合并，
李四的a.txt文件的第五行的“Typo”已经变为了“Type”，
第十行还是“She”，就是说Subversion已经将张三的修改“合并”到李四的a.txt文件中了。
之后，李四再执行Commit命令，就能将他对第十行的修改（将He改为She）
提交到服务器端的Repository中了（生成Revision12）。
但是这种合并在某些情况下会变得复杂一些，
比如：
李四对a.txt文件的修改并不是第十行，
而是与张三同样修改第五行的单词，
李四将“Typo”改为“Typr”，并且提交修改，
这时Subversion会提示李四在提交修改前，
这时Subversion将Revision11的a.txt文件与
李四修改的a.txt文件进行合并时发现李四修改的同样是第五行，
于是Subversion就无法判断是李四的修改（“Tpyr”）
正确还是张三的修改（“Type”）正确，
因为他们都是在Revision10的a.txt基础上作的修改。
这种情况叫做Conflict（冲突），
a.txt文件的图标会变成一个黄色三角。
这时，只能依靠李四自己去判断到底第三行应该修改为“Typr”还是“Type”。
当李四确定修改之后，在a.txt文件上单击右键，TortoiseSVN->
Resolved
告诉Subversion已经解决了Conflict。
这时再执行Commit命令就能提交修改（生成Revision12）。
Subversion这种控制方式保证了你对文件所作的修改都是基于文件的最新版本。
24、“.svn”目录
在客户端WorkingCopy的每一层目录中都会有一个“.svn”目录，
该目录是Subversion进行管理用的目录。
不要手动修改其中的文件。
该目录存储了WorkingCopy的一个副本
实际存储副本的地方是F:
\project1\.svn\text-base目录
\Project1是一个WorkingCopy，
该目录下有两个文件a.txt和b.txt还有一个子目录ccc，
子目录ccc中还有一个d.txt文件。
“.svn”目录中存储的是你最近一次执行完Update或者Commit命令之后当前目录中文件的副本，
\project1\.svn\text-base中存储的a.txt和b.txt
是最近一次执行完Update或者Commit命令之后F:
\project1下的a.txt和b.txt的拷贝。
也就是说你所作的修改都是基于“.svn”目录存储的那些文件。
这种机制可以让我们在不连接网络的情况下，
将WorkingCopy中的文件恢复到修改之前的状态。
Subversion的Revert命令就是利用了这种机制来实现的。
比如你修改了F:
\project1\a.txt文件，
这时你又改变了主意想放弃对该文件的修改，
你可以单击右键，TortoiseSVN->
修改过的F:
\project1\a.txt文件
就会被F:
\project1\.svn\text-base中a.txt文件的副本所替代，
使得a.txt恢复到修改前的状态。
WorkingCopy中每一个子目录下都会有一个“.svn”目录，
并不是只有最上层目录才有“.svn”目录。
所以，F:
\project1\ccc下也有一个“.svn”目录，
该目录存储的是F:
\project1\ccc\d.tx
升级会员 