Mario洁 发表于 2019-1-25 15:14:32

Subversion--Version Control

记住Subversion可以管理任何类型的文件集—-----它并非是程序员专用的。版本库是Subversion的核心部分,是数据的中央仓库。Subversion是一个“集中式”的信息共享系统.版本库以典型的文件和目录结构形式   文件系统树来保存信息。
Subversion听起来和一般的文件服务器没什么不同。事实上,Subversion的版本库的确是一种文件服务器,但不是“一般”的文件服务器。Subversion版本库的特别之处在于,它会记录每一次改变:每个文件的改变,甚至是目录树本身的改变,例如文件和目录的添加、删除和重新组织。版本控制系统的核心问题:设计用来记录和跟踪数据变化的系统。
版本模型版本控制系统的核心任务是实现协作编辑和数据共享,但是不同的系统使用   不 同的策略实现这个目的。Subversion本身支持不同的工作方式。
文件共享的问题我们有两个共同工作者,Harry和Sally,他们想同时编辑版本库里的同一个文件,如果首先Harry保存它的修改,过了一会,Sally可能凑巧用自己的版本覆盖了这些文件,Harry的更改不会永远消失(因为系统记录了每次修改),但Harry所有的修改不会出现在Sally新版本的文件中,所以Harry的工作还是丢失了—至少是从最新的版本中丢失了—而且可能是意外的,这就是我们要明确避免的情况!
锁定-修改-解锁 方案许多版本控制系统使用锁定-修改-解锁机制解决这种问题,在这样的模型里,在一个时间段里版本库的一个文件只允许被一个人修改。首先在修改之前,Harry要“锁定”住这个文件,锁定很像是从图书馆借一本书,如果Harry锁住这个文件,Sally不能做任何修改,如果Sally想请求得到一个锁,版本库会拒绝这个请求。在Harry结束编辑并且放开这个锁之前,她只可以阅读文件。Harry解锁后,就要换班了,Sally得到自己的轮换位置,锁定并且开始编辑这个文件。锁定-修改-解锁模型有一点问题就是限制太多,经常会成为用户的障碍:
[*]锁定可能导致管理问题。有时候Harry会锁住文件然后忘了此事,这就是说Sally一直等待解锁来编辑这些文件,她在这里僵住了。然后Harry去旅行了,现在Sally只好去找管理员放开锁,这种情况会导致不必要的耽搁和时间浪费。
[*]锁定可能导致不必要的线性化开发。如果Harry编辑一个文件的开始,Sally想编辑同一个文件的结尾,这种修改不会冲突,设想修改可以正确的合并到一起,他们可以轻松的并行工作而没有太多的坏处,没有必要让他们轮流工作。
[*]锁定可能导致错误的安全状态。假设Harry锁定和编辑一个文件A,同时Sally锁定并编辑文件B,如果A和B互相依赖,这种变化是必须同时作的,这样A和B不能正确的工作了,锁定机制对防止此类问题将无能为力—从而产生了一种处于安全状态的假相。很容易想象Harry和Sally都以为自己锁住了文件,而且从一个安全,孤立的情况开始工作,因而没有尽早发现他们不匹配的修改。锁定经常成为真正交流的替代品

拷贝-修改-合并 方案Subversion,CVS和一些版本控制系统使用拷贝-修改-合并模型,在这种模型里,每一个客户联系项目版本库建立一个个人工作拷贝—版本库中文件和目录的本地映射。用户并行工作,修改各自的工作拷贝,最终,各个私有的拷贝合并在一起,成为最终的版本,这种系统通常可以辅助合并操作,但是最终要靠人工去确定正误。拷贝-修改-合并模型感觉有一点混乱,但在实践中,通常运行的很平稳,用户可以并行的工作,不必等待别人,当工作在同一个文件上时,也很少会有交迭发生,冲突并不频繁,处理冲突的时间远比等待解锁花费的时间少。最后,一切都要归结到一条重要的因素:用户交流。当用户交流贫乏,语法和语义的冲突就会增加,没有系统可以强制用户完美的交流,没有系统可以检测语义上的冲突,所以没有任何证据能够承诺锁定系统可以防止冲突,实践中,锁定除了约束了生产力,并没有做什么事。什么时候锁定是必需的锁定-修改-解锁模型被认为不利于协作,但有时候锁定会更好。拷贝-修改-合并模型假定文件是可以根据上下文合并的:就是版本库的文件主要是以行为基础的文本文件(例如程序源代码)。但对于二进制格式,例如艺术品或声音,在这种情况下,十分有必要让用户轮流修改文件,如果没有线性的访问,有些人的许多工作就最终要被放弃。尽管Subversion一直主要是一个拷贝-修改-合并系统,但是它也意识到了需要锁定一些文件,并且提供这种锁定机制,
Subversion实践Subversion版本库URLsvn checkout http://svn.example.com:9834/repossvn checkout file://localhost/path/to/reposC:\> svn checkout file:///X:/path/to/repos

C:\> svn checkout "file:///X|/path/to/repos"
…$ svn checkout "http://host/path with space/project/españa"…Subversion会回避这些不安全字符,并且会像你输入了这些字符一样工作:
$ svn checkout http://host/path%20with%20space/project/espa%C3%B1a如果URL包含空格,一定要使用引号,这样你的脚本才会把它做一个单独的svn参数
工作拷贝一个典型的Subversion的版本库经常包含许多项目的文件(或者说源代码),通常每一个项目都是版本库的子目录,在这种布局下,一个用户的工作拷贝往往对应 版本库 的的一个子目录。为了得到一个工作拷贝,你必须检出(check out)版本库的一个子树,(术语“check out”听起来像是锁定或者保留资源,实际上不是,只是简单的得到一个项目的私有拷贝),举个例子,你检出 /calc,你可以得到这样的工作拷贝:$ svn checkout http://svn.example.com/repos/calc
A    calc/Makefile
A    calc/integer.c
A    calc/button.c
Checked out revision 56.

$ ls -A calc
Makefileinteger.cbutton.c.svn/列表中的A表示Subversion增加了一些条目到工作拷贝,你现在有了一个/calc的个人拷贝,有一个附加的目录—.svn—保存着前面提及的Subversion需要的额外信息。假定你修改了button.c,因为.svn目录记录着文件的修改日期和原始内容,Subversion可以告诉你已经修改了文件,然而,在你明确告诉它之前,Subversion不会将你的改变公开,将改变公开的操作被叫做提交(committing,或者是checking in)修改到版本库。将你的修改发布给别人,你可以使用Subversion的提交(commit)命令。$ svn commit button.c -m "Fixed a typo in button.c."
Sending      button.c
Transmitting file data .
Committed revision 57.$ pwd
/home/sally/calc

$ ls -A
.svn/ Makefile integer.c button.c

$ svn update
U    button.c
Updated to revision 57.svn update命令的输出表明Subversion更新了button.c的内容,注意,Sally不必指定要更新的文件,subversion利用.svn以及版本库的进一步信息决定哪些文件需要更新。Subversion可以通过多种方式访问—本地磁盘访问,或各种各样不同的网络协议,这要看你的管理员是如何设置,但一个版本库地址永远都只是一个URLSubversion的修订号是针对整个目录树的,而不是单个文件。每一个修订号代表了一次提交后版本库整个目录树的特定状态,另一种理解是修订号N代表版本库已经经过了N次提交。当Subversion用户讨论“foo.c的修订号5”时,他们的实际意思是“在修订号5时的foo.c”。需要注意的是,一个文件的修订版本N和M并不必有所不同。许多其它版本控制系统使用每文件一个修订号的策略,所以会感觉这些概念有点不一样。(以前的CVS用户可能希望察看附录 B, CVS用户的Subversion指南来得到更多细节。)

页: [1]
查看完整版本: Subversion--Version Control