Subversion最佳实践

原文地址 https://www.open.collab.net/nonav/scdocs/SVNTips.html

翻译:张永智, 2017.6.17

这是在您的日常软件开发工作中充分利用Subversion的一套快速指南。

使用一个合理的存储库布局

有很多方法可以放置你的资料库。 因为分支和标签是普通的目录,所以你需要在你的仓库结构中加以说明。

Subversion项目正式推荐了一个“项目根”的概念,它代表了一个项目的锚点。 “项目根”包含三个子目录:/trunk、/branches和/tags。 存储库可能只包含一个项目根,也可能包含多个。

图书参考:选择存储库布局(http://svnbook.red-bean.com/svnbook/ch05s04.html#svn-ch-5-sect-6.1

提交逻辑变更集

当您对代码进行提交到存储库时,请确保您的更改反映出单一目的:修复特定错误,添加新功能或某些特定任务。 您的提交将创建一个新的修订版本号,这个版本号可以永远被用作更改的“名称”。 您可以在缺陷数据库中提及此修订版本号, 或者将其用作svn merge的参数,如果要撤消更改或将其合并到另一个分支。

图书参考:“Subversion and Changesets”侧栏,在第4章内http://svnbook.red-bean.com/svnbook/ch04s03.html。

高效地使用问题跟踪系统

在Subversion更改集和您的问题跟踪数据库之间创建尽可能多的双向链接:

  • 如果可能,在每个提交日志消息中的包含特定问题ID。
  • 当将信息附加到问题(以描述进度或关闭问题)时,记录负责更改的修订版本号。

跟踪手动合并

当提交合并的结果时,请务必编写描述性的日志消息,说明合并的内容,如下所示:

Merged revisions 3490:4120 of /branches/foobranch to /trunk.

书籍参考:手动跟踪合并(http://svnbook.red-bean.com/svnbook/ch04s03.html#svn-ch-4-sect-3.2), 并将整个分支合并到另一个分支(http://svnbook.red-bean.com/svnbook/ch04s04.html#svn-ch-4-sect-4.1)。

了解混合版本的工作拷贝

您的工作拷贝的目录和文件可能处于不同的“工作”修订版本:这是一个特意的功能,允许您将较旧版本的东西与较新版本的混合在一起。

但是有些少量的事实你必须注意:

1, 每次svn提交后,您的工作副本都有混合版本。 您刚刚提交的文件现在处于HEAD修订版本,其他所有内容都是旧版本。

2, 某些提交是不允许的:
  • 您不能提交删除没有HEAD工作版本的文件或目录。
  • 您不能将属性更改提交给没有HEAD工作版本的目录。

3, svn update将把您的整个工作副本都带到一个工作版本,并且是第2点提到的问题的典型解决方案。

图书参考:混合修订的限制(http://svnbook.red-bean.com/svnbook/ch02s03.html#svn-ch-2-sect-3.4)

耐心等待大文件处理

Subversion的一个很好的特点是通过设计,它可以处理文件的大小没有限制。 文件在Subversion客户端和服务器之间的两个方向上都以“流式”方式发送,在网络的每一侧都使用小量不变的内存。

当然,还有一些实际的问题需要考虑。虽然不需要担心千字节大小范围内的文件(例如典型的源代码文件), 但提交较大文件可能需要大量的时间和空间(例如数十或数百兆字节大的文件)。

首先,请记住,您的Subversion工作副本将所有版本控制文件的原始副本存储在.svn/text-base/区域中。 这意味着您的工作副本占用磁盘空间是原始数据集的至少两倍。除此之外,Subversion客户端遵循提交文件的(当前不可调整的)算法:

  • 将文件复制到.svn/tmp/(可能需要一段时间,暂时使用额外的磁盘空间)
  • 在tmpfile和原始副本之间执行二进制差异,或者如果新添加的文件,在tmpfile和空文件之间执行二进制diff。 (可能需要很长时间来计算,尽管最终通过网络发送少量数据)
  • 将差异发送到服务器,然后将tmp文件移动到.svn/text-base/

因此,尽管文件大小没有理论上的限制,但您需要注意,在您的客户端停止时,非常大的文件可能需要相当多的耐心等待。 然而,您可以放心,与CVS不同,您的大文件不会使服务器失效或影响其他用户。

知道何时创建分支

这是一个激烈辩论的问题,它的确取决于你的软件项目的文化。 而不是普遍适用的策略,我们将在这里描述三个常见的情况。

永不分支策略

(通常由尚不能运行代码的新兴项目使用)

  • 用户在/trunk上进行日常工作。
  • 当用户开始执行一系列复杂的更改时,偶尔/trunk“中断”(不能编译或功能测试不通过)。

优点:很容易遵循的政策。 新开发人员进入门槛较低。 不需要学习如何创建分支或合并。

缺点:混沌发展,代码随时可能不稳定。

一个附注:这种开发在Subversion中比在CVS中的风险要小一些。 因为Subversion提交是原子的,所以在其他人正在提交的过程中, 检出或更新不可能收到“部分”提交。

始终分支策略

(经常用于重管理和监督的项目)

  • 每个用户为每个编码任务创建专用分支上进行工作。
  • 当编码完成时,有人(原始编码人,对等体或管理人员)会检查所有专用分支的更改并将其合并到/trunk。

优点:/trunk始终保持非常稳定。

缺点:人为地彼此隔离,可能会产生比必要更多的合并冲突。 需要用户做大量额外的合并工作

按需创建分支策略

(这是Subversion项目所使用的分支策略。)

  • 用户在/trunk上进行日常工作。
  • 规则#1:/trunk必须一直编译并通过回归测试。 违反这项规定的承诺者是公开羞辱的。
  • 规则#2:单个提交(变更集)不能太大,以防止危害同行审查。
  • 规则#3:如果规则#1和#2发生冲突(即不可能在不干扰主干的情况下进行一系列小提交)

那么用户应该创建一个分支并在那里提交一系列较小的更改集。 这允许同行评议,并且不会中断/trunk的稳定性。

优点:/trunk始终保持稳定。 分支/合并有时候相当的麻烦。

缺点:为用户日常工作增加一些负担:每次提交之前都必须进行编译和测试。