分类： 项目管理
2008-11-03 17:50:57
SVN提供了一套非常优秀的版本控制方案。在这里我把官方的文档和自己实际使用中遇到的一些常见的问题列在这里，以后还会陆续更新。
版本控制有哪些方案
所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？版本库里意外覆盖别人的更改非常的容易。
文件共享的问题
考虑这个情景，我们有两个共同工作者，Harry 和 Sally，他们想同时编辑版本库里的同一个文件，如果首先 Harry 保存它的修改，过了一会，Sally 可能凑巧用自己的版本覆盖了这些文件，Harry 的更改不会永远消失(因为系统记录了每次修改)，Harry 所有的修改不会出现在 Sally 的文件中，所以 Harry 的工作还是丢失了—至少是从最新的版本中丢失了—而且是意外的，这就是我们要明确避免的情况！
图 2.2. 需要避免的问题
锁定-修改-解锁 方案
许多版本控制系统使用锁定-修改-解锁这种机制解决这种问题，在这样的模型里，在一个时间段里版本库的一个文件只允许被一个人修改。首先在修改之前，Harry 要“锁定”住这个文件，锁定很像是从图书馆借一本书，如果 Harry 锁住这个文件，Sally 不能做任何修改，如果 Sally 想请求得到一个锁，版本库会拒绝这个请求。在 Harry 结束编辑并且放开这个锁之前，她只可以阅读文件。Harry 解锁后，就要换班了，Sally 得到自己的轮换位置，锁定并且开始编辑这个文件。
图 2.3. 锁定-修改-解锁 方案
锁定-修改-解锁模型有一点问题就是限制太多，经常会成为用户的障碍:
锁定可能导致管理问题。有时候 Harry 会锁住文件然后忘了此事，这就是说 Sally 一直等待解锁来编辑这些文件，她在这里僵住了。然后 Harry 去旅行了，现在 Sally 只好去找管理员放开锁，这种情况会导致不必要的耽搁和时间浪费。
锁定可能导致不必要的线性化开发。如果 Harry 编辑一个文件的开始，Sally 想编辑同一个文件的结尾，这种修改不会冲突，设想修改可以正确的合并到一起，他们可以轻松的并行工作而没有太多的坏处，没有必要让他们轮流工作。
锁定可能导致错误的安全状态。假设 Harry 锁定和编辑一个文件 A，同时 Sally 锁定并编辑文件 B，如果 A 和 B 互相依赖，这种变化是必须同时作的，这样 A 和 B 不能正确的工作了，锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态的假相。很容易想象 Harry 和 Sally 都以为自己锁住了文件，而且从一个安全，孤立的情况开始工作，因而没有尽早发现他们不匹配的修改。
复制-修改-合并 方案
Subversion，CVS 和一些版本控制系统使用复制-修改-合并模型，在这种模型里，每一个客户读取项目版本库建立一个私有工作副本—版本库中文件和目录的本地映射。用户并行工作，修改各自的工作副本，最终，各个私有的复制合并在一起，成为最终的版本，这种系统通常可以辅助合并操作，但是最终要靠人工去确定正误。
这是一个例子，Harry 和 Sally 为同一个项目各自建立了一个工作副本，工作是并行的，修改了同一个文件 A，Sally 首先保存修改到版本库，当 Harry 想去提交修改的时候，版本库提示文件 A 已经过期，换句话说，A 在他上次更新之后已经更改了，所以当他通过客户端请求合并版本库和他的工作副本之后，碰巧 Sally 的修改和他的不冲突，所以一旦他把所有的修改集成到一起，他可以将工作副本保存到版本库。
图 2.4. 复制-修改-合并 方案
图 2.5. 复制-修改-合并 方案(续)
但是如果 Sally 和 Harry 的修改重叠了该怎么办？这种情况叫做冲突，这通常不是个大问题，当 Harry 告诉他的客户端去合并版本库的最新修改到自己的工作副本时，他的文件 A 就会处于冲突状态: 他可以看到一对冲突的修改集，并手工的选择保留一组修改。需要注意的是软件不能自动的解决冲突，只有人可以理解并作出智能的选择，一旦 Harry 手工的解决了冲突(也许需要与 Sally 讨论)，他就可以安全的把合并的文件保存到版本库。
复制-修改-合并模型感觉是有一点混乱，但在实践中，通常运行的很平稳，用户可以并行的工作，不必等待别人，当工作在同一个文件上时，也很少会有重叠发生，冲突并不频繁，处理冲突的时间远比等待解锁花费的时间少。
最后，一切都要归结到一条重要的因素: 用户交流。当用户交流贫乏，语法和语义的冲突就会增加，没有系统可以强制用户完美的交流，没有系统可以检测语义上的冲突，所以没有任何证据能够承诺锁定系统可以防止冲突，实践中，锁定除了约束了生产力，并没有做什么事。
有一种情况下锁定-修改-解锁模型会更好，也就是你有不可合并的文件，例如你的版本库包含了图片，两个人同时编辑这个文件，没有办法将这两个修改合并，Harry 或 Sally 会丢失他们的修改。
Subversion 怎么做？
Subversion 缺省使用复制-修改-合并模型，大多数情况下可以满足你的需求。然而，Subversion 1.2 后还是支持锁定，如果你有不可合并的文件，或者你只是想实行强制管理策略，Subversion 仍然会提供你需要的特性。
TortoiseSVN是什么
TortoiseSVN是windows下其中一个非常优秀的SVN客户端工具。通过使用它，我们可以可视化的管理我们的版本库。不过由于它只是一个客户端，所以它不能对版本库进行权限管理。
TortoiseSVN不是一个独立的窗口程序，而是集成在windows右键菜单中，使用起来比较方便。
TortoiseSVN每个菜单项都表示什么意思
SVN Update
从版本库中获取最新的一份工作拷贝，关于工作拷贝和版本库的关系，参见下面的文档。
--------------
SVN Commit
把自己工作拷贝所做的修改提交到版本库中，这样别人在获取最新版本(Update)的时候就可以看到你的修改了。
--------------
Show log
显示当前文件(夹)的所有修改历史。SVN支持文件以及文件夹独立的版本追溯。
----------
Repo-Browser
查看当前版本库，这是TortoiseSVN查看版本库的入口，通过这个菜单项，我们就可以进入配置库的资源管理器，然后就可以对配置库的文件夹进行各种管理，相当于我们打开我的电脑进行文件管理一样。
----------
Revision Graph
查看当前项目或文件的修订历史图示。如果项目比较大型的话，一般会建多个分支，并且多个里程碑（稳定版本发布），通过这里，我们就可以看到项目的全貌。
----------
Resolved
如果当前工作拷贝和版本库上的有冲突，不能自动合并到一起，那么当你提交修改的时候，tortoisesvn就会提示你存在冲突，这时候你就可以通过这个菜单项来解决冲突。冲突的解决有两种，一种是保留某一份拷贝，例如使用配置库覆盖当前工作拷贝，或者反过来。还有一种是手动解决冲突，对于文本文件，可以使用tortoiseSVN自带的工具，它会列出存在冲突的地方，然后你就可以和提交者讨论怎么解决这个冲突。同时它也对Word有很好的支持
--------------
Update to Revision
从版本库中获取某一个历史版本。这个功能主要是方便查看历史版本用，而不是回滚版本。注意：获取下来之后，对这个文件不建议进行任何操作。如果你做了修改，那么当你提交的时候SVN会提示你，当前版本已失效（即不是最新版本），无法提交，需要先update一下。这样你所做的修改也就白费了。
---------------
Revert
如果你对工作拷贝做了一些修改，但是你又不想要了，那么你可以使用这个选项把所做的修改撤销
--------------
Cleanup
如果当前工作拷贝有任何问题的话，可以使用这个选项进行修正。例如，有些文件原来是版本控制的，但是你没有通过tortoiseSVN就直接删除了，但是tortoiseSVN还是保留着原来的信息（每个文件夹下都有一个.svn的隐藏文件夹，存放着当前文件夹下所有文件夹的版本信息）所以这就会产生一些冲突。可以使用cleanup来清理一下。
------------------
GetLock/ReleaseLock
如果你不想别人修改某个文件的话，那么你就可以把这个文件进行加锁，这样可以保证只有你对这个文件有修改权。除非你释放了锁，否则别人不可能提交任何修改到配置库中
-----------------
Branch/tag
Branch是分支的意思。例如当在设计一个东西的时候，不同的人有不同的实现，但是没有经过实践检验，谁也不想直接覆盖掉其他人的设计，所以可以引出不同的分支。将来如果需要，可以将这些分支进行合并。
tag是打标签的意思。通常当项目开发到一定程度，已经可以稳定运行的时候，可以对其打上一个标签，作为稳定版。将来可以方便的找到某个特定的版本（当然我们也可以使用版本号来查找，但是数字毕竟不方便）
SVN对于分支和标签都是采用类似Linux下硬链接的方式（同一个文件可以存在两个地方，删除一个不会影响另一个，所做修改会影响另一个），来管理文件的，而不是简单的复制一份文件的拷贝，所以不会有浪费存储空间的问题存在。
-------------
Switch
主要用来切换到不同分支用的
-------------
Merge
合并当前的工作拷贝和版本库上相应的文件
-------------
Export
这个功能是方便我们部署用。当我们需要发布一个稳定版本时，就可以使用这个功能将整个工程导出到某个文件夹，新的文件夹将不会包含任何版本信息了。
-------------
Relocate
当我们版本库发生转移的时候就需要用到这个功能了。例如我原先的版本库是建在U盘上的，现在转移到（复制整个配置库文件夹）开发服务器上，使用https代替文件系统的访问。因此就需要将原来的工作拷贝的目标版本库重新定位到开发服务器上。
-------------
Add
将没有被版本控制的文件添加到版本库中，注意：Add操作不会自动提交到配置库中，必须再次commit。你也可以在上层文件夹直接commit来添加尚未版本控制的文件（夹）
-------------
create patch
创建补丁。如果管理员不想让任何人都随便提交修改，而是都要经过审核才能做出修改，那么其他人就可以通过创建补丁的方式，把修改信息（补丁文件）发送给管理员，管理员审核通过之后就可以使用apply patch提交这次修改了。
如何将现有工程版本控制？
在服务器端（可以和客户端在同一个机器上）建立一个空的版本库，然后在已有工程文件夹右键检出到该版本库，然后再在已有工程文件夹上进行提交commit
如何将文件回滚至某个特定的版本
选择需要回滚的文件（夹），点击show log查看历史版本记录，这个时候会弹出下面的对话框
选择Revert to this revision,这个时候，会将你工作拷贝里面该文件回滚到这个版本（相当于你在最新版本上面不断的ctrl-z撤销，而版本号还是最新的版本号，然后你所做的修改还是相当于基于最新版本所做的修改），然后你就可以在这个版本上面进行修改，然后再提交了。或者直接提交也可以。注意：回滚只是将工作拷贝的回滚到某个版本，而不是更新版本库，只有当你回滚之后再次提交版本库才会更新，别人再次update的时候才能得到你回滚的版本。
Update Item to revision 和Revert to this Revision有什么区别?
update的意思是更新，revert的意思是撤销。
更新至某一个版本的意思是获取版本库中的某一个特定的版本到工作拷贝里。需要注意的是，如果你在上面做修改的话，那么你是在基于旧版本的基础上做修改，当你提交的时候SVN会提示你您当前工作拷贝版本已经过期（即不是基于版本库最新版本来做修改的），这个时候你必须先update到最新版本。
这个功能一般是用于获取一份只读拷贝用，例如你有一个工程用到了某个版本的dll，有一天有人把dll修改了并且提交了，然后你update到最新版本时发现编译不通过了，这个时候如果你想暂时先使用旧版本的话，那么你可以使用update to this revision的功能。
revert的功能主要用来进行版本库回滚用的，当你发现某个版本的文件不是很好想恢复到某个特定版本，这个时候你就可以使用这个功能。关于revert的具体信息可以参考上一条FAQ
为什么老提示我版本过期You Revision is out of date？
当你获取了一个最新版本之后，你在上面做了修改，在这期间，有人更新了配置库，这个时候如果你打算提交你的修改的时候，SVN就会提示你你当前工作拷贝的版本已经过期，必须先update到最新版本。这样才能保证每个人所做的修改不会被意外覆盖。注意：只有基于最新版本上的修改才可以提交到版本库
为什么有时候会出现莫名其妙的错误？
当你checkout某个工程到你的工作拷贝文件夹里头的时候，SVN会在每个文件夹里头建立一个.svn的隐藏文件夹(事实上它的名字并不是真的是.svn，只不过windows把真正的文件名隐藏掉了)，这个文件夹里头包含了当前文件夹下所有文件/文件夹等的索引信息，这样SVN通过把当前文件/文件夹的一些信息和.svn目录下的索引进行比较就知道该文件有没有被修改过了。因此.svn这个文件夹非常重要，不能轻易直接删除，否则会出现莫名其妙的错误。
