svn日常使用指南及常见错误.docx

svn日常使用指南及常见错误.docx

《svn日常使用指南及常见错误.docx》由会员分享，可在线阅读，更多相关《svn日常使用指南及常见错误.docx（39页珍藏版）》请在冰豆网上搜索。

svn日常使用指南及常见错误

SVN日常操作及常见错误

1.SVN简介

1.1什么是TortoiseSVN？

TortoiseSVN是Subversion版本控制系统的一个免费开源客户端，可以超越时间的管理文件和目录。

文件保存在中央版本库，除了能记住文件和目录的每次修改以外，版本库非常像普通的文件服务器。

你可以将文件恢复到过去的版本，并且可以通过检查历史知道数据做了哪些修改，谁做的修改。

这就是为什么许多人将Subversion和版本控制系统看作一种“时间机器”。

某些版本控制系统也是软件配置管理（SCM）系统，这种系统经过精巧的设计，专门用来管理源代码树，并且具备许多与软件开发有关的特性-比如，对编程语言的支持，或者提供程序构建工具。

不过Subversion并不是这样的系统；它是一个通用系统，可以管理任何类型的文件集，包括源代码。

1.2TortoiseSVN的特性

1.重载图标

每个版本控制的文件和目录的状态使用小的重载图标表示，可以让你立刻看出工作副本的状态。

2.目录版本控制

CVS只能追踪单个文件的历史，但是Subversion实现了一个“虚拟”文件系统，可以追踪整个目录树的修改，文件和目录都是版本控制的，结果就是可以在客户端对文件和目录执行移动和复制命令。

3.原子提交

提交要么完全进入版本库，要么一点都没有，这允许开发者以一个逻辑块提交修改。

4.高效的分支和标签

分支与标签的代价不与工程的大小成比例，Subversion建立分支与标签时只是复制项目，使用了一种类似于硬链接的机制，因而这类操作通常只会花费很少并且相对固定的时间，以及很小的版本库空间。

5.良好的维护能力

Subversion没有历史负担，它由一系列良好的共享C库实现，具有定义良好的API，这使Subversion非常容易维护，可以轻易的被其他语言和程序使用。

1.3安装TortoiseSVN

TortoiseSVN提供一个容易使用的安装程序。

双击安装程序文件并按照提示操作。

安装程序将会完成剩余的步骤。

TortoiseSVN的界面已经翻译成了许多种语言，所以你可以下载符合你要求的语言包。

你可以在我们的翻译状态页[

每一种语言包都是一个.exe安装程序，只要根据向导运行安装程序，当你下一次启动程序时，翻译就会生效。

2.版本库

2.1版本模型

2.1.1文件共享的问题

考虑这个情景，我们有两个共同工作者，Harry和Sally，他们想同时编辑版本库里的同一个文件，如果首先Harry保存它的修改，过了一会，Sally可能凑巧用自己的版本覆盖了这些文件，Harry的更改不会永远消失（因为系统记录了每次修改），Harry所有的修改不会出现在Sally的文件中，所以Harry的工作还是丢失了—至少是从最新的版本中丢失了—而且是意外的，这就是我们要明确避免的情况！

图2.2.需要避免的问题

2.1.2锁定-修改-解锁方案

图2.3.锁定-修改-解锁方案

锁定-修改-解锁模型有一点问题就是限制太多，经常会成为用户的障碍:

•锁定可能导致管理问题。

有时候Harry会锁住文件然后忘了此事，这就是说Sally一直等待解锁来编辑这些文件，她在这里僵住了。

然后Harry去旅行了，现在Sally只好去找管理员放开锁，这种情况会导致不必要的耽搁和时间浪费。

•锁定可能导致不必要的线性化开发。

如果Harry编辑一个文件的开始，Sally想编辑同一个文件的结尾，这种修改不会冲突，设想修改可以正确的合并到一起，他们可以轻松的并行工作而没有太多的坏处，没有必要让他们轮流工作。

•锁定可能导致错误的安全状态。

假设Harry锁定和编辑一个文件A，同时Sally锁

定并编辑文件B，如果A和B互相依赖，这种变化是必须同时作的，这样A和B不能正确的工作了，锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态

的假相。

很容易想象Harry和Sally都以为自己锁住了文件，而且从一个安全，孤立的情况开始工作，因而没有尽早发现他们不匹配的修改。

2.1.3复制-修改-合并方案

Subversion，CVS和一些版本控制系统使用复制-修改-合并模型，在这种模型里，每一个客户读取项目版本库建立一个私有工作副本—版本库中文件和目录的本地映射。

用户并行工作，修改各自的工作副本，最终，各个私有的复制合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。

图2.4.复制-修改-合并方案

图2.5.复制-修改-合并方案（续）

但是如果Sally和Harry的修改重叠了该怎么办？

这种情况叫做冲突，这通常不是个大问题，当Harry告诉他的客户端去合并版本库的最新修改到自己的工作副本时，他的文件A就会处于冲突状态:

他可以看到一对冲突的修改集，并手工的选择保留一组修改。

需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择，一旦Harry手工的解决了冲突（也需要与Sally讨论），他就可以安全的把合并的文件保存到版本库。

复制-修改-合并模型感觉是有一点混乱，但在实践中，通常运行的很平稳，用户可以并行的工作，不必等待别人，当工作在同一个文件上时，也很少会有重叠发生，冲突并不频繁，处理冲突的时间远比等待解锁花费的时间少。

最后，一切都要归结到一条重要的因素:

用户交流。

当用户交流贫乏，语法和语义的冲突就会增加，没有系统可以强制用户完美的交流，没有系统可以检测语义上的冲突，所以没有任何证据能够承诺锁定系统可以防止冲突，实践中，锁定除了约束了生产力，并没有做什么事。

有一种情况下锁定-修改-解锁模型会更好，也就是你有不可合并的文件（即二进制文件），例如你的版本库包含了图片，两个人同时编辑这个文件，没有办法将这两个修改合并，Harry或Sally会丢失他们的修改。

2.2.2版本库访问URL

方案

访问方法

file:

//

直接版本库访问（本地磁盘或者网络磁盘）。

http:

//

通过WebDAV协议访问支持Subversion的Apache服务器。

https:

//

与http:

//相似，但是用SSL加密。

svn:

//

通过未认证的未认证的TCP/IP自定义协议访问svnserve服务器。

svn+ssh:

//

通过认证并加密的认证并加密的TCP/IP自定义协议访问svnserve服务器。

2.2版本库布局

/trunk主开发目录

/branches分支目录，每个用户可以在开发的过程中创建分支进行开发，然后通过合并成为完成的项目（我们项目中放入的是版本分支）

/tags具有特殊意义的版本目录。

（我们项目中放在branches中）

3．日常使用指南

3.1基本的工作循环

典型的工作周期是这样的：

1.更新你的工作拷贝。

•svnupdate

2.做出修改

•svnadd

•svndelete

•svncopy

•svnmove

3.检验修改

•svnstatus

•svndiff

4.可能会取消一些修改

•svnrevert

5.解决冲突（合并别人的修改）

•svnupdate

•svnresolved

6.提交你的修改

•svncommit

3.1.1更新工作副本

选择•svnupdate更新功能，用来更新其他人对上次工作副本的更改，以达到本机副本与版本库资源一致。

3.1.2修改工作副本

在本地工作副本进行相应的修改后，将所做的修改预添加到版本库，即使用add功能菜单，将本地修改用svn进行管理控制

3.1.3检查你的修改

当你完成修改，你需要提交他们到版本库，但是在此之前，检查一下做过什么修改是个好主意，通过提交前的检查，你可以整理一份精确的日志信息，你也可以发现你不小心修改的文件，给了你一次恢复修改的机会。

此外，这是一个审查和仔细察看修改的好机会。

你可以通过与资源库进行对比，知道自己修改了什么：

1.在myeclipse或eclipse下svn插件：

选中需要同步的目录，右键选择“Team——>与资源库同步”：

即可以看到本地修改和资源库其他人所做的修改：

：

为资源库中其他人做了修改的文件

：

为本地工作副本所做修改的文件

：

所有做了修改的文件

：

冲突文件

选中要对比的文件，右键选择“openincompareeditor“:

即可以看到当前资源库中的最新内容与本地工作副本所做的修改有哪些：

然后根据本地工作副本与资源库中的最新内容的不同，进行更新、合并、手动解决冲突等操作。

2.在Tortoisesvn客户端下：

可以选中菜单CheckForModifications：

即可以看到本地修改文件：

点击“comparewithbase”（与资源库同步），则可以看到该文件在本地所做的修改：

上面的工具条：

可以将资源库中的内容更新到本地工作副本中。

点击下面的按钮“checkRepository”则可以看到版本库中其他人所做的修改：

其他操作同上，也可以看到文件与本地工作副本的更改，并可以进行合并、冲突解决等一系列操作。

3.1.4取消本地修改

假定我们在看本地与资源库修改的输出，你发现对某个文件的所有修改都是错误的，或许你根本不应该修改这个文件，或者是从开头重新修改会更加容易。

这是使用svnrevert的好机会。

Subversion把文件恢复到未修改的状态，叫做.svn目录的“原始”拷贝，应该知道svnrevert可以恢复任何预定要做的操作，举个例子，你不再想添加一个文件或者你不小心删除了一个文件，只要选中该文件或目录，右键选择Team——>还原操作：

1.myeclipse和eclipse的svn插件下的还原操作：

2.在Tortoisesvn客户端下还原操作：

使用还原操作则可以讲本地所做的修改取消，与资源库保持一致。

3.1.5解决冲突（合并别人的修改）

在svn文件提交的过程中，经常会出现有冲突的现象，在svn中一般以红色标记作为警示。

冲突分为两种情况：

1.两人同时对一个文件进行了修改，但是两人所修改的地方没有重叠，这个时候可以先将版本库中的最新文件更新到本地，然后再将本地工作副本所做的修改提交到版本库中

2.两人同时对一个文件进行了修改，并且两人所做的修改有重叠的地方，这个时候就必须要进行手动的解决冲突。

情况1我们可以不必关心，这种情况下文件干净的接受了版本库的变化，但是在情况2下，当你执行更新操作的时候，则会出现下面的情况：

在控制台答应出的日志信息中会出现c标记的svn信息，说明服务器上的改动同你的改动冲突了，你需要自己手工去解决。

当冲突发生了，有三种情况可以帮助你注意到这种情况和解决冲突。

1.subversion打印c标记，并且标记这个文件已冲突。

2.如果subversion认为这个文件是可合并的，它会置入冲突标记——特殊的的横线分开冲突的“两面”——在文件里可视化的描述重叠的部分

3.对于每一个冲突文件，subversion放置三个额外的未版本化文件到你的工作拷贝：

Filename.mine你更新前的文件，没有冲突标志，只有你最新更改的内容。

（如果subversion认为这个文件不可以合并，.mine文件不会创建，因为它和工作文件相同）

Filename.rOLDREV这是你做更新操作以前的Base版本文件，就是你在上次更新之后未作更改的版本

Filename.rNEWREV这是你的Subversion客户端从服务器刚刚收到的版本，这个文件对应版本库的HEAD版本

这里OLDREV是你的.svn目录中的修订版本号，NEWREV是版本库中的HEAD版本号。

在这种情况下，Subversion不允许你提交application.properties文件，直到你的三个临时文件被删掉。

如果遇到冲突，三件事你可以选择：

1.手动合并冲突文本（检查和修改文件中的冲突标志）

2.用某个临时文件覆盖你的工作文件

3.运行svnrevert来放弃所有的修改

一旦你解决了冲突，你需要通过命令svnresolved让subvision知道，这样就会删除三个临时文件，Subversion就不会认为这个文件是在冲突状态，就可以对这个文件进行提交了。

把冲突文件置为已解决后，文件则为可提交状态。

3.1.5.1手工合并冲突

由于不良的交流，冲突随时可能会发生，可以先看一个简单的例子，来进行冲突的手动更改。

首先，当你遇到冲突后，更新了这个文件，就会在这个文件中看到如下情况：

小于号、等于号和大于号串是冲突标记，并不是冲突的数据，你一定要确定这些内容在下次提交之前得到删除，前两组标志中间的内容是你在冲突区所做的修改：

后两组之间是版本库中的最新内容：

通常你可以通过对比自己本地修改和版本库的最新内容进行合并，并删除掉冲突标志，如果你修改文件时感到混乱，你可以参考subversion生成的三个文件——包括你未做更新的文件，你也可以使用第三方的合并工具检验这三个文件。

修改完成后，执行resolved命令，将冲突标记为已解决，即可将合并后的内容提交。

3.1.5.2拷贝覆盖你的工作文件

如果你只是希望取消你的修改，，你可以仅仅拷贝subversion为你生成的文件替换你的工作拷贝，即执行覆盖更新操作。

便可将本地修改替换成版本库最新内容。

3.1.5.3使用svnrevert（还原操作）

如果你得到冲突，经过检查你决定取消自己的修改并且重新编辑，你可以恢复你的修改。

注意：

当你恢复一个冲突文件时，不需要再运行svnresolved。

现在我们准备好提交修改了，在任何你认为解决了冲突的时候，小心运行svnresolved，一点删除了临时文件，Subvision会让你提交这文件，即使文件中还存在冲突标记。

、

3.1.6提交你的修改

最后你的修改结束了，你合并了服务器上的所有修改，即可使用commit命令将你的修改提交到版本库。

当提交修改的时候，可以提供一些描述性信息，方便其他客户端用户在更新的时候明白你所提交的文件的意图及所做的修改。

4.检验历史

4.1myeclipse和eclipse插件

在myeclipse或eclipse中使用svn插件，执行显示“资源库历史记录”即可以查看版本库中的历史记录：

单击右键，则会出现以下视图：

在右键菜单中，可以通过SwitchtoRevisionREV将本地工作副本切换为当前版本。

通过“比较”可以将本地工作副本的文件同版本库中的各个版本进行比较，做了哪些修改。

如：

选择需要对比的版本（一般直接默认即可）：

通过比较后，可以看到一共修改的三个文件，然后点击单个文件，进行单一的比较。

4.2Tortoise客户端

Tortoise客户端，则可以通过showlog来进行历史记录的查看：

单击右键，出现如下视图：

Comparewithworkingcopy可以与本地工作副本进行对比。

Showchangesasunifieddiff以统一的区别方式显示所有的修改，如：

将本次修改的所有文件进行了比对显示。

Comparewithpreviousrevision则可以与以前的版本历史进行比较，如：

选中其中一个文件，双击，即可看到版本修改内容的比较：

5.分支与合并

分支与标签和合并是所有控制系统的共同概念。

在版本库布局中我们已经讲到过。

5.1什么是分支？

假设你的工作是维护本公司一个部门的手册文档，一天，另一个部门问你要相同的手册，但一些地方会有“区别”，因为他们有不同的需要。

这种情况下你会怎样做？

显而易见的方法是：

作一个版本的拷贝，然后分别维护两个版本，只要任何一个部门告诉要做一些小修改，你必须选择在对应的版本进行更改。

你也许希望在两个版本同时作修改，举个例子，你在第一个版本发现了一个拼写错误，很显然这个错误也会出现在第二个版本里。

两份文档几乎相同，毕竟，只有许多特定的微小区别。

这是分支的基本概念—正如它的名字，开发的一条线独立于另一条线，如果回顾历史，可以发现两条线分享共同的历史，一个分支总是从一个备份开始的，从那里开始，发展自己独有的历史。

分支与开发

5.2使用分支

5.2.1创建分支

例如：

我们为项目testSVN创建两个分支，如下：

分别检出这两个分支：

并分别对文件index.jsp进行修改，提交。

在分支进行开发的过程中，拥有的是自己独立的历史记录，再合并前，是看不到其他分支的修改的。

5.2.2合并

针对上面的例子，我们在主目录trunk目录下的项目进行合并操作：

点击合并后，显示视图如下：

选择该分支下的版本：

选择版本后，进行合并操作：

完成合并操作后：

index.jsp文件发生冲突，文件内容为：

Test.jsp已经合并到trunk项目下，可见合并操作已成功。

对于发生冲突的文件，以常规的处理冲突的手法进行解决冲突即可。

可以在资源库历史中看到合并文件：

在分支目录中，也可以进行合并操作，与上描述一致。

Torsion上的svn合并操作：

可以在此界面解决冲突，冲突解决完后，进行完成冲突操作。

或者不解决，直接进行合并操作（直接关闭冲突窗口）。

如果不解决冲突，在合并的过程中会看到testSVN目录下的index.jsp发生冲突：

Index.jsp中的内容为：

直接对index.jsp进行手动冲突解决，在执行标记为已解决，就可以了。

6．其他

6.1图标重载

图4.1.显示重载图标的资源管理器

TortoiseSVN最明显的特性之一就是图标重载，重载的图标显示在你的工作副本文件上。

你一眼就可以看到文件被修改过了。

一个新检出的工作副本使用绿色的对勾做重载。

表示Subversion状态正常.

在你开始编辑一个文件后，状态就变成了已修改，而图标重载变成了红色感叹号。

通过这种方式，你可以很容易地看出哪些文件从你上次更新工作副本后被修改过，需要被提交。

如果在更新的过程中出现了冲突，图标会变成黄色感叹号。

如果你给一个文件设置了svn:

needs-lock属性，Subversion会让此文件只读，直到你获得文件锁。

具有这个重载图标的文件来表示你必须在编辑之前先得到锁。

如果你拥有了一个文件的锁，并且Subversion状态是正常，这个重载图标就提醒你如果不使用该文件的话应该释放锁，允许别人提交对该文件的修改。

这个图标表示当前文件夹下的某些文件或文件夹已经被调度从版本控制中删除，或是该文件夹下某个受版本控制的文件丢失了。

加号告诉你有一个文件或目录已经被调度加入版本控制。

横条告诉你有一个文件或目录被版本控制系统所忽略。

这个图标重载是可选的。

这个图标说明文件和目录未被版本控制，但是也没有被忽略。

这个图标重载是可选的。

6.1.1本地与远程状态

图4.13.检查修改

通常知道你修改了哪些文件以及哪些文件已经由另人修改并提交了是很有用的。

这就是命

令TortoiseSVN®CheckForModifications...的用武之地了。

这个对话框显示了所有你的工作副本中进行了任何形式的修改的的文件，也包括了当前存在的未受控的文件。

蓝色

本地被修改过的项

紫色

增加的项。

那些被加入的项在文本状态列中有个+号表示，工具提示（tooltipshows）显示

了该项是从哪里复制来的。

深红

删除的或是丢失的项。

绿色

在本地和版本库中都有被修改过的项。

改动将在更新的时候被合并。

这种情况很可能在更新的时候产生冲突。

亮红

在本地被修改过但在版本库中已经被删除的项，或者在版本库中被修改但在本地被删除的项。

这种情况必将在更新时产生冲突。

黑色

未修改和未受控的项。

6.2清理操作（锁定）

当计算机出现意外终止进程，再执行svn的时候就会出现文件锁定的错误，这个时候我们只要执行以下clearup的操作就可以了。

但是如果文件时真的被其他人锁定就要沟通解决锁定问题。

如果Svn提示你要进行清除操作，这个时候我们也要进行清除操作，然后才能对svn进行进一步的操作。

7.常见错误

1.showlog只显示nodate在SVN中选中一个目录showlog时，出现了某些版本只显示版本号和（nodate），没有其他信息，什么原因引起的？

出现了（nodate）的revision，为其他人修改了你所没有权限访问的某个目录下的文件

2.提示错误信息：

svn:

Commitfailed（detailsfollow）:

svn:

Item'/test/test2'isoutofdate

一般情况下为版本库中有其他人修改了此文件，并提交到了版本库。

你需要做的事先将本地的备份出来，然后将版本库中的文件更新下来，再进行合并修改提交到版本库中。

3.目标机器积极拒绝，无法连接'或Can'tconnecttohost的原因

当出现'目标机器积极拒绝，无法连接'或svn:

Can'tconnecttohost...时，请依次检查下面各项：

1，服务器有没有运行，有没有打开相应端口

如果服务器是svnserve，检查有没有运行svnserve，有没有打开3690端口

如果服务器是apache，检查apahce是否运行，是否打开80端口

检查时可以在服务器运行netstat-na看看相应端口是否在LISTEN

2，防火墙有没有开放相应端口

3，客户端是否可以连接服务器的相应端口

使用命令telnet服务器IP相应端口

如：

telnet192.168.0.13690

4.用Delete键直接删除文件与文件夹处理方式不同，为什么？

开发中经常会有开发人员直接用Delete键将文件或者文件夹删除后再提交，SVN报错。

但是文件和文件夹的处理方式不同。

如果删除的是文件可以直接在SVN的检查更新中将文件的文字状态由缺少改为删除再提交即可。

但是，如果删除的是文件夹则不行，只能重新update一下，再用SVN的删除操作。

为什么呢？

请问，这两种有什么不一样吗？

如果是文件夹还有别的其他的办法吗？

在本地工作拷贝文件夹里面还有svn的本地配置信息,并且这个配置文件是隐藏的.在你删除文件夹的时候会一并被删除,那么本地关于文件或文件夹的配置信息将与服务器端不相匹配,故你不能顺利提交!

如果只是文件的话,那么在检查的时候,没有找到该文件,系统就视为该文件已经独立删除了.

5.怎样让版本库中的项目返回至以前的某个版本？

选中本地拷贝文件夹，右键－>TrosiseSVN->显示日志，弹出的对话框中选中要恢复的版本，