Blogs

Appearance

团队里把 SVN 用顺的几条约定 ​

SVN 的命令不算多，但如果团队没有统一约定，现场会非常碎。

我更在意的是下面这些边界是否说清楚，而不是每个人会不会背命令。

约定 1：主干是集成线，不是实验场 ​

  • trunk 放相对可集成、可发布的代码
  • 新需求、重构、联调、热修，都优先开到 branches

不要因为 SVN 分支看起来像目录复制，就嫌麻烦直接全堆在主干上。

约定 2：提交前先同步，再确认现场 ​

我觉得最少要做：

shell
svn update
svn status
svn diff

SVN 的 commit 直接进中央仓库，这个动作天然比 Git 里的本地 commit 更需要克制。

约定 3：重命名和移动必须走版本控制命令 ​

shell
svn move old-name.ts new-name.ts

不要在 Finder、资源管理器、IDE 里直接拖来拖去，然后希望 SVN 自动理解你的意图。

约定 4：标签是快照，不继续开发 ​

text
/tags/release-1.2.0

这种目录我建议默认只读心态。要修线上版本，就从标签或发布分支再切热修分支，不要直接在标签上继续改。

约定 5：二进制文件明确走锁 ​

如果项目里有设计稿、Office 文件、导出包之类不适合自动合并的内容，团队要提前说好：

  • 哪些目录强制 needs-lock
  • 锁的申请和释放怎么做
  • 长时间占锁时要不要在群里同步

这种约定越早立，后面越少扯皮。

约定 6：合并前工作副本必须干净 ​

我自己的底线是：

  • 先 svn status
  • 确认没有一堆和本次合并无关的改动
  • 再做 svn merge

脏现场合并不是不能成功，而是成功了也很难让人放心。

约定 7：修订号要能被清楚引用 ​

SVN 团队很适合直接用修订号沟通：

  • “这个修复在 r218”
  • “发布分支先挑 r221 和 r223”

如果团队能把修订号、需求单号、发布说明连起来，后面查问题会省很多时间。

最后一条 ​

SVN 协作里最值钱的不是命令表，而是大家都知道：

  • 什么能直接做
  • 什么动作要先同步
  • 什么现场必须先收干净

只要这些边界清楚，SVN 其实没有很多人想象得那么难用。