-----------------------------
原来不是URL变了，那么按songs_0319的方法应该就可以了
1、 如下图所示，经常碰到的冲突提交失败。
2、 首先在编辑之前先把svn上面的内容更新下来，保证是在最新的版本上修改的，不然还是会提示冲突的。然后选择目标文件右键，选择“svn“。
3、 在d出列表里选择”获取锁定“。
4、这样就可以正常的编辑，然后选择svn提交进行编辑。
5、编辑完之后就可以正常提交了，这个时候锁定会自动打开。
SVN是subversion的缩写，是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理，简而言之就是用于多个人共同开发同一个项目，实现共享资源，实现最终集中式的管理。
SVN的作用：SVN是一种技术性更加安全的产品，的实现了系统和控制两方面的结合。一方面可以将系统整体的安全功能有效地分布在分支系统中，进而保证分支系统能正常运行，从而使各分支系统能够互补，最终在系统整体性的安全性得以保障，通过均衡原则实现最终追求安全的目的。
扩展资料：
SVN服务器既具有CVS所具有数据储存的优点，像是信息资源存储后会形成资源树结构，便于存储的同时，数据一般不会丢失，同时又拥有自己的特色。SVN是通过关系数据库及二进制的存储方式，同时解决了既往不能同时读写同一文件等问题，同时增添了自己特有的“零或一”原则。
参考资料来源：百度百科-版本控制
参考资料来源：百度百科-SVN
SVN一种集中式文件版本管理系统，对于开发人员来讲，应该是有必要掌握的工具，当然还有其他比如CVS,VSS等其他工具。
一个开放源代码的版本控制系统，相较于RCS、CVS，它采用了分支管理系统，它的设计目标就是取代CVS。互联网上很多版本控制服务已从CVS迁移到Subversion。
注意事项：
SVN服务器既具有CVS所具有数据储存的优点，像是信息资源存储后会形成资源树结构，便于存储的同时，数据一般不会丢失，同时又拥有自己的特色。SVN是通过关系数据库及二进制的存储方式，同时解决了既往不能同时读写同一文件等问题，同时增添了自己特有的“零或一”原则。
百度百科-版本控制
百度百科-SVN
排除人为损坏的可能性考虑是SVN服务器中的有执行权限的软件或者病毒对文件进行了改动和保存。首先利用杀毒软件对全盘进行查杀，无果。后来分析了一下服务器中安装的软件，安装的软件比较简单，只有系统软件和某大厂杀毒软件，然后考虑是否是杀毒软件误杀导致，结果在该杀毒软件的隔离区内找到了其中一份PDF的副本，点击恢复和加白名单后，PDF文件正常打开。
此时问题得到解决，原来是杀毒软件误查，将PDF中部分内容修改但未删除，原始文件副本保存在隔离区中，后续打开会以安全模式打开。但当下载到其他电脑打开，或者本电脑隔离区副本清除后，因为缺失原始文件副本，就会导致文件数据丢失。通过副本恢复且加白名单后即可复原。不幸的是，中间这段时间服务器的杀毒软件可能执行了自动清理垃圾或者隔离区有时间限制的原因，导致另一PDF文件副本从隔离区彻底消失，无法恢复，还好该PDF是软件版本迭代说明文档，内容较少。21 文件检出
安装TortoiseSVN后，SVN会跟Windows的资源管理器完美集成。点击右键，我们可以在菜单栏中选择“SVN检出”选项，输入要检出代码的文件库的URL地址，我们就可以检出该URL地址下的文件库的文件。默认情况下是检出最新版本的代码，如果需要，我们可以通过浏览日志，根据日志来找出想要的版本，然后在“版本”选项中指定相应版本就可以检出相关代码了 。
之后，对于同一个项目的主干开发，我们都在这个检出的代码文件目录下 *** 作，而不是每一次提交或更新都重新检出一次。
22 文件添加
我们在本地创建的文件(包括目录)不会受SVN的控制，为了让其接受SVN的控制必须将其添加到文件库中。对于团队其他成员需要的文件，如代码文件、某些模块的a文件（由于某些需要，该模块代码不公开），我们必须让它们接受SVN的控制，并且保持最新的版本。
23 文件删除
当我们需要删除无用的文件(包括目录)时，不能使用Windows的资源管理工具，而必须使用SVN本身的删除文件功能。这样该文件被删除后，其所有修改历史仍然保存在SVN服务器中，以后仍然可以获得该文件的修改历史。
24 文件改名
当我们需要对文件(包括目录)进行改名的时，不能使用Windows的资源管理工具，而必须使用SVN本身的文件改名功能。这样该文件被改名后，其改名前的所有修改历史仍然保存在SVN服务器中，保持连续的修改信息。
25 文件更新
其他团队成员提交到SVN上的改动不会自动更新到你的本地拷贝中来，我们需要通过更新文件 *** 作来获取其他成员对项目文件所做的修改。SVN更新文件 *** 作会把文件库里的文件与本地文件进行合并，从而达到了同时保留其他成员的修改及本地的修改的目的。如果无法自动合并则会发生冲突，需要使用文件比较工具进行手工合并，合并完成后才能提交已解决冲突的文件。冲突的详细解决方法见第三章——冲突解决。
在团队开发时，更新是一件很重要的工作，可以保持团队成员之间的工作内容一致，因此要注意经常更新自己的工作拷贝，以保证自己能够获得最新的修改内容。
26 改动提交
我们对文件(包括目录)所做的一切改动，包括添加、删除、修改文件都必须提交到SVN服务器文件库中才能正式生效，之后团队的其他成员才可以获取你所作的修改。
提交是很重要的一项 *** 作，要求做到：
提交代码之前一定要保证修改后的代码能编译通过，不能提交编译不通过的代码。
比较修改前及修改后的代码，把调试信息或其他不相关的信息去掉，再次确保提交的代码是正确的并且提交的是需要提交的文件。
不要等到修改了很多代码才提交，而是相关小功能完成时就应该提交一次。这样以后发现问题时就很容易撤销有问题的代码——因为撤销只能针对一次提交，所以在一次提交里涉及过多的功能是不推荐的。
提交时必须填写log信息，说明这次提交增加了什么功能或者修正了什么bug。这些信息有助于自己和其他团队成员了解整个项目的历史。当出现问题时也方便定位到对应的版本代码，所以log信息必须足够详细。
事务性提交。也就是说提交要么成功，要么全部失败——即提交出现错误时会自动回滚，实际上没有提交任何东西。出现错误时，解决错误，再次提交上次提交的全部内容即可。
3 冲突解决
冲突的解决是我们使用SVN过程中的一个棘手问题，所以独立一节来谈论。
31 冲突的产生
冲突发生在多个成员同时对同一个文件进行修改的情形下。即当有其他成员已经提交了修改，而自己在本地拷贝中也对该文件进行了修改，而且修改的是同一个地方，那么在进行本地文件的更新时，SVN会不知道该选择那个修改（SVN上的修改还是本地的修改）来进行合并，所以冲突就产生了。
举例说，假如受SVN控制的文件Daytxt在SVN服务器上的当前内容如下：
图表 3 Daytxt文件在本地的修改
我们可以看到，在文本的第一行，SVN上及本地都做了修改。这样当在本地进行更新（提交之前必须先更新），SVN合并时就不知道monday后面到底该是work还是sleep，所以冲突就产生了。
而第三、五行是各自进行了修改，并没有冲突，所以这两行可以顺利合并，合并后可以看到所有人所做的修改。
32 冲突的解决
冲突发生后，SVN会在本地保存该文件的不同修改版本，见下图蓝色图标：
图表 4 Daytxt文件的不同版本
Daytxtr35是版本35的Daytxt文件（本地拷贝最新版本）
Daytxtr37是版本37的Daytxt文件（SVN上最新版本）
Daytxtmine的是本地修改后的Daytxt文件
Daytxt文件中包含了合并后的内容
321 简单冲突解决
对于简单的内容冲突，我们可以直接在合并后的文件上修改。在上例中，我们打开Daytxt文件，可以看到SVN合并后的内容：
图表 5 Daytxt合并后内容
我们看到没有冲突的修改：(play basketball)及（meeting）顺利地合并了，而冲突的部分出现了一些标记。其中标记
<<<<<<< mine
=======
之间包含的是本地修改的冲突部分的内容，即monday(work)。而标记
=======
>>>>>>> r37
之间包含的是版本37（SVN上最新版本）该部分内容，即monday(sleep)。
不失一般性，假如我们现在要保留的内容是monday(work)，那么我们只要把标记及monday(sleep)部分内容去掉即可：
图表 6 Daytxt解决冲突后内容
确保修改正确后，把Daytxt文件设置为“已解决的”。
图表 7 Daytxt标记为已解决
之后，后缀为mine,r35,r37文件全部消失，仅保留已解决冲突的Daytxt文件，提交到SVN即可。
322 复杂冲突解决
对于文件内容复杂的文件，上述的解决方法容易漏掉一些要修改的部分，解决起来也耗时耗力。这时要通过SVN提供的工具来解决。
选择SVN功能“编辑冲突”，打开冲突编辑工具:
图表 8 冲突编辑工具
上半部分的两个内容栏分别显示的是版本37的内容及本地修改的内容。
下半部分的内容栏显示的是合并后的内容。
每个内容栏左边的标记清楚地标识了该文件做了那些修改。
文件冲突的部分用红色显眼地表示了出来。在合并栏，点击冲突部分，点击右键，我们可以选择用哪个内容（SVN上最新内容或者本地修改内容）来解决冲突部分，也可以选择两个内容都使用，同时选择它们出现的先后顺序。
逐一解决各个冲突。确保所有冲突都解决后，保存文件，并标记为“已解决”的，退出该工具即完成冲突的解决。
4 加锁策略
事实上，解决冲突还有一种方法，那就是“严格加锁”。
“严格加锁”要求在编辑文件之前必须先对文件加锁，然后才能进行编辑。此时团队其他成员不能对该文件进行编辑，即保证了同一时刻只有一个人在编辑该文件，因此避免了冲突的出现。
那么，什么类型的文件我们应该采取“严格加锁”呢？
Excel、等不可合并的文件，我们必须对其“严格加锁”。“严格加锁”的文件都标记为“可读”的，即不可编辑。要编辑这些“严格加锁”的文件，必须先对其加锁，加锁后文件更改为“可读可写”。编辑完这类文件后要第一时间提交。提交完成时，SVN会自动解开任何你拥有的锁 。
文本文件，比如程序代码，SVN通常可以为我们合并改动，无须“严格加锁”。对于一些大家都频繁改动的重要源代码文件，可能会引起大量冲突，我们也不推荐“严格加锁”，因为加锁会导致大家持续得走来走去去询问加锁情况。正确做法是把文件分成数个逻辑单元，大家都修改各自的单元，减少合并时的冲突。
5 标签&分支
一个项目最初存放的目录我们称之为主干(trunk)。下面我们讨论除了主干之外其他存放项目的目录——标签(tag)和分支(branch)。
51 标签（tag）
版本号可以区分多次的代码修改，我们可以使用版本号来检出需要的代码，但对于重要版本的代码，如第三版发布代码，我们不希望记住r37这样的数字。这时，我们就可以通过创建标签来对SVN中这个发布版本的文件的这个时刻的状态创建一个“快照”，以后就可以通过这个标签名字来检出第三发布版本的代码。
标签其实是当前项目文件的简单拷贝，保存在标签所在的目录下。创建标签也是挺简单的，不过要注意：
标签的名字一定要有描述性，可以仅凭名字就知道为什么要创建标签。
不能过多地使用标签，只有在重要时刻或者发布版本时才可以创建标签。
标签是项目文件在某个时刻的状态，不能对其进行修改 。
52 分支（branch）
分支跟标签一样，也是当前项目文件的简单拷贝，保存在分支所在的目录下。
分支跟标签的根本区别在于，标签不能对其进行修改，而分支就是为了某种目的的修改而建立的。在检出代码时检出指定分支即可，分支的 *** 作跟主干上的 *** 作完全相同。
521 何时创建
遇到下述情况，我们可以通过创建分支来解决问题：
发布分支
当我们快要发布一个版本了，一个开发小团队要为这次发布做好准备，比如说修改一些收尾的bug。这时他们需要的是项目的稳定性，而同时我们还有其他团队要开发预计下次发布才会添加进去的功能，显然他们不能在同一份代码上工作，因此我们需要从主干中建立出一个发布分支，发布团队都从这个发布分支检出及提交代码。当程序被发布之后，这个分支依然是活动的。这样，如果客户报告了一些bug，团队会在这个发布分支中修正它们并视情况合并到主干中去。
试验分支
当我们需要对项目做大范围的改动，并且这改动对系统的其余部分有深远的影响，而我们又不能保证这次改动一定能成功的时候就可以建立试验分支。如果试验失败了，可以废弃这个分支；成功了我们只要把分支的改动合并到主干代码中去就可以了。
其他情况，我们不建议创建分支，更不推荐在分支上创建分支，因为分支过多，合并时的冲突将会是一种难于解决的灾难。
522 合并分支
我们在分支上所修正的bug很可能在主干上或者其他分支上也存在，因为它们往往来自同一份代码，所以我们在分支上所做的改动有必要合并到主干或者其他分支中去。
对于简单的bug，一次提交就能解决问题的，那么我们只要记住提交新版本号，然后使用新版本号把改动合并到其他的受影响的主干及分支中去就可以了。
对于复杂的bug，可能需要多个开发者花几天的时间提交多次才能修好。这时光用版本号来记住修改的内容就有点勉为其难了。因此，我们可以使用标签来标记我们修正过程的开始和结束，然后使用这些标签帮助我们把修正的代码合并到主干和其他分支中去。整个过程如下：
① 给分支打个标签，标记bug修改开始。
② 测试重现bug，修正代码让新测试通过。
③ 提交你的改动到SVN上。
④ 重复步骤2、3，直到确定bug已经修正。
⑤ 再给分支打个标签，标记bug修正结束。
⑥ 使用两个标签来把修正的代码合并到所有其他受影响的主干和分支上。
6 注意事项
经常更新
由于文件可能有多个人修改，应该经常更新你的工作拷贝中的文件，这样能降低发生冲突的可能性。
测试提交
提交前先在本地进行测试。不允许将有错误的文件提交到SVN服务器上。
填写备注
提交时一定要写备注：备注有助于其他人（包括三个月后的你自己）理解你对文件所做的修改。
整体提交
提交文件时注意要提交一项改动所对应的所有文件，不要一次提交一个文件或者一次提交修改了很多功能的一堆文件。
发布标签
对于每一个发布的版本都要建立标签：当用户告诉你发生某个问题时，你可以迅速地追踪到问题是在哪个版本引入的 。
附：测试自动化小组SVN使用指导原则
1 Project的构建
Project在SVN服务器上的目录架构如下：
SVN上的项目文件：
1 必须保证Trunk上的代码是最新的！定期对Trunk上的代码进行更新，各小组可根据各自实际情况自己把握
2 Tag是根据项目需要所打的标签，每一个发布的版本都要打Tag，主要是方便有需要时可以直接根据Tag返回到之前的状态，以便于分析、测试；Tag中必须包含相应的release文件及当时编译或发布时的源代码，必须有相关的文档注明项目背景、发布情况等。
3 Branch文件夹可以用作备份用，可以用个人名字命名文件夹；此外，Branch分支主要用来进行短暂或者探索性的开发使用，最终的软件版本必须更新、合并到Trunk主干上。
4 关于同一项目组开发环境的建议：同一项目组成员的开发环境最好一致，软件安装路径和Project文件存放路径最好一致。
2 版本号
关于版本号命名规则：主版本号子版本号修正版本号
1 项目初版本时，版本号为010；
2 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1；
3 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0；
4 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1，子版本号和修正版本号复位为0；
5 编译版本号一般是编译器在编译过程中自动生成的，我们只定义其格式，如果编译器不能自动生成，人手添加，数值代表为当前的系统时间。
例子：V101 Build090305 Rel111123
其它版本使用规则：
1 α（alphal）内部测试版
此版本表示该软件仅仅是一个初步完成品，只在组内内部交流，该版本软件的 bug 较多，限内部测试使用。
例子：V011 Build090305 alphal1
2 β（beta）外部测试版
该版本相对于α版已有了很大的改进，经过组内的测试，消除了严重的错误，但还是存在着一些缺陷，需要经过大规模测试来进一步消除。
例子：V012 Build090305 beta1
3 demo 演示版
仅限评审或讲解时做介绍使用。
例子：V013 Build090305 demo1
4 release 最终版
该版本意味“最终释放版”，在出了一系列的测试版之后，终归会有一个正式版本，一般情况下，release不会以单词形式出现在软件封面上，取而代之的是符号 (Rel) 。release版本发布时，必须将待发布的软件和相应版本更新记录打包在一起发出。
例子：V101 Build090305 Rel111123
3 权限限制
如果项目本身需要对项目组成员作不同的权限控制，可以考虑维护两个工程：一个工程里面有相应的源文件，一个则只有编译后的文件。
4 模块的版本维护
1 文件一般不需要版本，但要有详细的更新历史记录；
2 模块可以以版本来维护，具体可以不同的文件夹区分。TortoiseSVN常见的16个使用问题：
1、鼠标右键点击 文件 时CPU占用100％
每次右键点击文件，CPU飙升到100％（同时右键菜单被显示。）如果从菜单中选择某项，则CPU又恢复正常；如果在空白处点击右键，CPU将不会有问题，到底是怎么回事？
XP包含了一个已知的bug，当你在特定的配置文件下访问上下文菜单会引起cpu占用上升到100%。这个bug会使文件复制暂停，使网络连接缓慢，流媒体（声音，视频）扭曲。 为了工作在包含这个 bug 的环境下，你需要通过以下 *** 作禁止图形界面的传输效果：
控制面板-》显示
选择外表栏
点击效果，然后清空“为菜单和工具提示使用以下过渡效果”栏
点击确定关闭所有的对话框。
另一种解决方法是在点击右键显示上下文菜单前点击一次左键。
2、是否可以创建一个本地的版本库到网络文件夹？
不能创建 Berkeley DB 版本库到共享的网络 地址 ！
BDB 版本库 不能 存在于远程文件系统，比如NFS，AFS，或者Windows SMB。 BDB要求文件系统运行在严格的POSIX语义环境，更重要的是，将文件直接映射到进程 内存 的能力。很多没有网络的文件系统都提供了这个功能。 如果你尝试在网络共享中使用BDB，结局是不可预知的。你可能会立刻看到诡异的错误，或者在几个月以后，你发现版本库隐约被毁坏。
你可以使用 FSFS 格式 的版本库但只有一个用户可以访问本地 硬盘 ，接下来的FAQ项目会讲到为什么共享版本库是一个坏想法。 除非你真的有迫切的原因让你的文件放到网络共享，通常来说，最好的办法就是避免这样做。
如果你真的需要通过网络共享访问FSFS版本库，你应该按照下面的其中一点来做：
用下面的语法规则来映射网络 驱动 器：
将//server/shared映射到S：
file:///S:/repos （盘符前有三个斜杠）
通过下面的格式指定一个UNC直接路径：
Subversion 》= 12
file://server/shared/repos （2个斜杠）
Subversion 《 12 （奇怪的语法，我们知道）
file://///server/shared/repos （5个斜杠）
file:///server/shared/repos （3个斜杠+反斜杠）
但是不要说我们没有提醒过你……
3、是否可以将版本库保存在网络共享驱动器来代替创建服务器？
如果你需要多个电脑访问版本库，在理论上你可以创建 FSFS 版本库（但不能是 BDB 版本库）在网络共享驱动器上，通过已下格式访问 file:// protocol。事实上这里有三个不推荐的原因：
你将给所有用户直接访问权限，所以他们会有可能偶然的 删除 或者破换版本库文件系统。
并不是所有的网络共享协议都支持Subversion要求的锁定。总有一天你会发现你的版本库被悄悄的破坏。
你不得不设置正确的访问权限，SAMBA 在这一点上特别难以满足。
更好的办法是创建一个真正的服务器进程（像Apache，svnserve），存储版本库到当地的文件系统上，使版本库服务器可以在网络上有效，可以被访问。这也许会比你想的要简单。Subversion书中 第6章 服务器配置 有详细的方法说明。
4、是否可以使用不同的Subversion客户端来 *** 作同一个工作拷贝？
可以，客户端只是用来控制你的工作拷贝，以及工作拷贝与版本库之间的交互。工作拷贝里的元数据对于不同的客户端来说都是一样的。
但是，必须是使用同一版本Subversion库的客户端。TortoiseSVN 所使用的Subversion版本会在安装文件的文件名里标明，其它的客户端也会有类似说明。版本号的头两位数一致的客户端才能通用。例如，所有使用Subversion15x 的客户端都可通用（‘x’表示此位数字不影响兼容性）
你还必须确保这些客户端都是为同一个 *** 作系统编译的。客户端兼容的前提是必须是同一种 *** 作系统，并且元数据的表示方式可能发生变化。你不可以 对同一个工作拷贝同时使用Windows的原生客户端和Cygwin的客户端。如果是通过网络共享的工作拷贝，你不可以 同时使用Windows的客户端和Linux的客户端。
5、TortoiseSVN能实时自动转换文本文件中的换行符吗？
请到查看Subversion书中关于svn:eol-style属性的内容。 比如说，如果你将此属性设置为‘native’，在 Linux 下它就会以LF作为换行符， Windows 下则是 CRLF。想了解如何通过TortoiseSVN设置这些属性，请到 这里 阅读我们的文档。
6、如果冲突是在一个文件夹的属性里，怎样找到它呢？
在属性有冲突的文件夹里，有一个dir_conflictsprej文件，用文本 编辑器 打开它，你会看到有冲突的属性，用你想保留的属性覆盖有冲突的。
7、我误删了一个文件，怎么找回来？
如果你还没提交，你可以在被删除的文件/文件夹的父文件夹作 还原 *** 作。
如果你已经提交了删除文件，你可以使用版本库浏览器，回到那文件还存在时的版本，然后在上下文菜单中使用 拷贝到…… 命令，输入你工作拷贝的路径作为目标路径，被删除的文件就会从版本库复制到你的的工作拷贝。
用这个方法也可以恢复被删除的目录。
如果用这个方法恢复文件/目录后，日志对话框无法显示它的修改历史，别担心，历史信息还在的。在 SVN 中复制一个文件时，它的历史信息会同时被复制。但TortoiseSVN的查看日志功能默认是“Stop on copy”，即当你查看的日志是由分支点开始的。之所以这么做是因为当查看一个真正的分支时，你多数只是想知道那个分支的历史信息。如果要看完整的历史信息，你可以不选 ‘Stop on copy’，而把‘Get All’选上。
8、为什么我右击一个链接的时候有几个TortoiseSVN菜单？
这是正常的，其中一个是针对链接本身（lnk-file 文件），另外一个针对它指向的文件。这样既可以对一个链接文件进行版本控制，又可以对它指向的目标进行控制。事实上在文件菜单里你会有多达三个菜单（上下文菜单只显示二个）。
9、能不能像 Visual Source Safe 一样使用‘共享文件’？
Subversion中不能共享一个文件，但可以共享一个文件夹。请查看 Subversion Book中外部定义一章。
10、没有服务器，可以单独使用 TortoiseSVN 吗？
可以，你可以用file://协议来访问你的本地版本库。
11、使用TortoiseProc时可以发送用户名和 密码 吗？
TortoiseSVN 是一个 图形化客户端，它会在需要的时候提示你输入用户名和密码。如果你想以非交互方式访问版本库，可以使用命令行客户端。
12、版本分支图是怎么一回事？
版本分支图跟TortoiseSVN的其它功能不一样。它可以显示一个文件或文件夹的所有历史修订，包括拷贝、移动、分支和加标记 *** 作。
我们经常会被问到“为什么要把版本库根目录的日志也拿下来”，或者是“为什么会需要取由第一次修订到最新一次修订的全部日志呢”
我得澄清一点：这可不是因为我们太懒，或是笨到不会优化——尽管你们有些人似乎就是这么暗示的。我们这么做其实是有必要的。
版本分支图是通过查找针对某个对象的所有修订，来呈现它的历史的，这需要用到所有的可用信息。
如果查看选定文件/文件夹的日志，在日志对话框的下半部分你可以看到选中的修订影响到的所有路径，这就是在版本分支图用到的信息。如果查看/trunk的日志，你会发现里面没有记录加标记或分支的日志，就算是对/trunk本身加标记、作分支也不会有。 --》 这就是取版本库根目录日志的用意：只有版本库根目录日志才包含这些所需信息，包括一个目录何时曾被复制、分支、打标记或移动到何处。
沿用前面的例子，如果我们不取所有修订的日志，而只取一部分的，那就有可能丢失/trunk作分支、打标记的日志。而且即使那些分支、标记本身做过修改，或者那些日志也在取下的部分里，版本分支图也无法知道那些分支、标记 *** 作是在/trunk还是别的路径发生的。这意味着，版本分支图不单是不完整的，还有可能是错的。
因此我们不会去做所谓的“优化”，如果这个图一时正确一时错误，而且你还无从判断它是否正确、什么时候正确，这比完全没用的东西更糟糕。
13、通过 svn+ssh 提交时，为什么日志里没有‘作者’信息？
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）