Subversion1.2 Manual
From PHPBB用户手册
Contents |
前言
序言
读者
怎样阅读本书
本书约定
排版习惯
图标
本书的组织结构
本书是免费的
致谢
来自Ben Collins-Sussman
来自Brian W. Fitzpatrick
来自C. Michael Pilato
介绍
Subversion是什么?
Subversion的历史
Subversion的特性
Subversion的架构
安装Subversion
Subversion的组件
快速入门
基本概念
版本库
版本模型
文件共享的问题
锁定-修改-解锁 方案
拷贝-修改-合并 方案
Subversion实战
工作拷贝
修订版本
工作拷贝怎样追踪版本库
混合修订版本的工作拷贝
更新和提交是分开的
混合修订版本非常正常
混合修订版本很有用
混合修订版本也有限制
摘要
指导教程
帮助!
导入
修订版本: 号码、关键字和日期
修订版本号
修订版本关键字
修订版本日期
初始化的Checkout
基本的工作周期
更新你的工作拷贝
修改你的工作拷贝
检查你的修改
svn status
svn diff
svn revert
解决冲突(合并别人的修改)
手工合并冲突
拷贝覆盖你的工作文件
下注:使用svn revert
提交你得修改
检验历史
svn log
svn diff
比较本地修改
比较工作拷贝和版本库
比较版本库与版本库
svn cat
svn list
关于历史的最后一个词
其他有用的命令
svn cleanup
svn import
摘要
分支与合并
什么是分支?
使用分支
创建分支
在分支上工作
分支背后的关键概念
在分支间拷贝修改
拷贝特定的修改
合并背后的关键概念
合并的最佳实践
手工追踪合并
预览合并
合并冲突
关注还是忽视祖先
常见用例
合并一条分支到另一支
取消修改
找回删除的项目
常用分支模式
发布分支
特性分支
转换工作拷贝
标签
建立最简单的标签
建立复杂的标签
分支维护
版本库布局
数据的生命周期
摘要
如何恢复到以前的版本
方法一: 使用TortoiseSVN进行回滚.
这种方法只适用于windows平台. 以下摘自 TortoiseSVN文档:
使用版本日志对话框
如果想恢复某个版本或者版本范围的变更,最简单的方法是使用版本日志对话框。这种方法也可以用来撤销最近的若干次变更,把以前的某个版本变成最新版。
- 选中想要恢复变更的文件或者文件夹。如果想要恢复所有的变更,需要选中最顶层的文件夹。
- 选择TortoiseSVN → 显示日志,显示出版本列表。有可能需要使用全部显示或者下100 按钮,把想要恢复的版本显示出来。
- 选中想要恢复的版本。如果想要恢复一个版本范围,选中想要恢复的第一个版本,按住shift键,然后选中想要恢复的最后一个版本。注意,当恢复多个版本的时候,这些版本必须在列表中是连续的。用鼠标右键点击选中的版本(段),然后选择右键菜单 → 恢复这些版本的变更。
- 如果想要把以前的某个版本变成最新版本,右键点击选中的版本(范围),然后选择右键菜单 → 恢复到此版本。就能够撤销被选中版本后面所有的变更。
工作拷贝已经恢复到了变更以前的状态。检查恢复后的结果,然后提交变更。
使用合并对话框
如果要撤销更大版本范围的变更,可以使用合并对话框。上一个方法在后台使用了合并的机制,在这个方法里我们直接使用合并功能。
- 在工作拷贝上选择TortoiseSVN → 合并。
- 在起始:文本框里输入想要恢复的变更所在的分支或标签的URL。它也将作为默认URL。
- 在起始版本文本框里输入当前工作拷贝的版本号。如果能够保证没有其他人会提交变更,可以使用最新版本。
- 确认使用“起始:”的 URL检查框处于被选中的状态。
- 在结束版本里输入想要恢复到的版本号。比如,想要恢复的最小版本号的前一个版本号。
- 点击合并按钮完成合并。
工作拷贝已经恢复到了变更以前的状态。检查恢复后的结果,然后提交变更。
使用svndumpfilter
因为TortoiseSVN绝不会丢弃数据,所以那些被回滚的版本仍然以中间版本的形式被保留在版本库里。只是最新版本已经回到了以前的状态。如果想让版本库里的某些版本彻底消失,擦去这些版本曾经存在过的所有痕迹,就必须采取更极端的手段。不推荐使用这种方法,除非有很好的理由。比如某人向一个公开的版本库里提交了一份机密文件。
从版本库里删除数据的唯一方法就是使用svnadmin这个Subversion命令行工具。具体如何实现请参考Subversion手册。
方法二: 使用SubVersion自带的svn merge 命令
这种方法适用于任何能使用SubVersion的平台. 以下摘自 <使用SubVersion进行版本控制> 4.4.2节:
svn merge另一个常用的做法是取消已经做得提交,假设你愉快的在/calc/trunk工作,你发现303版本对integer.c的修改完全错了,它不应该被提交,你可以使用svn merge来“取消”这个工作拷贝上所作的操作,然后提交本地修改到版本库,你要做得只是指定一个相反的区别:
$ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk U integer.c $ svn status M integer.c $ svn diff … # verify that the change is removed … $ svn commit -m "Undoing change committed in r303." Sending integer.c Transmitting file data . Committed revision 350.
我们可以把版本库修订版本想象成一组修改(一些版本控制系统叫做修改集),通过-r选项,你可以告诉svn merge来应用修改集或是一个修改集范围到你的工作拷贝,在我们的情况例子里,我们使用svn merge合并修改集#303到工作拷贝。
记住回滚修改和任何一个svn merge命令都一样,所以你应该使用svn status或是svn diff来确定你的工作处于期望的状态中,然后使用svn commit来提交,提交之后,这个特定修改集不会反映到HEAD版本了。
继续,你也许会想:好吧,这不是真的取消提交吧!是吧?版本303还依然存在着修改,如果任何人取出calc的303-349版本,他还会得到错误的修改,对吧?
是的,这是对的。当我们说“删除”一个修改时,我们只是说从HEAD删除,原始的修改还保存在版本库历史中,在多数情况下,这是足够好的。大多数人只是对追踪HEAD版本感兴趣,在一些特定情况下,你也许希望毁掉所有提交的证据(或许某个人提交了一个秘密文件),这不是很容易的,因为Subversion设计用来不丢失任何信息,每个修订版本都是不可变的目录树 ,从历史删除一个版本会导致多米诺效应,会在后面的版本导致混乱甚至会影响所有的工作拷贝。 [9]
解释一下, svn merge -r 303:302 http://svn.example.com/repos/calc/trunk 这个命令是把当前目录当作工作拷贝. 如果想指定工作拷贝路径(如: c:\test), 则命令变成以下:
svn merge -r 303:302 http://svn.example.com/repos/calc/trunk c:\test

