从 git 迁到 svn，求教大家单位上 svn 都是怎么用的？

[zioc]

trunk 为主开发目录， branches 为分支开发目录， tags 为 tag 存档目录（不允许修改）。但是具体这几个目录应该如何使用， svn 并没有明确的规范，更多的还是用户自己的习惯。

对于这几个开发目录，一般的使用方法有两种。

1.第一种方法，使用 trunk 作为主要的开发目录
一般的，我们的所有的开发都是基于 trunk 进行开发，当一个版本 /release 开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过 hook 来进行管理）。此时应该基于当前冻结的代码库，打 tag 。当下一个版本 /阶段的开发任务开始，继续在 trunk 进行开发。
此时，如果发现了上一个已发行版本（ Released Version ）有一些 bug ，或者一些很急迫的功能要求，而正在开发的版本（ Developing Version ）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的 tag ，做相应的分支（ branch ）进行开发。

2.第二种方法，在每一个 release 的 branch 中进行各自的开发， trunk 只做发布使用。
这种开发模式当中， trunk 是不承担具体开发任务的，一个版本 /阶段的开发任务在开始的时候，根据已经 release 的版本做新的开发分支，并且基于这个分支进行开发。

第一种好还是第二种呢？

需求就是：
1.0 发布了，做 2.0 时，发现 1.0 有很急的 bug 要解决（需要发布 1.0.1 版），如果这些 bug 在 1.0 解决了，怎么更新到 2.0 呢？

[Phariel]

竟然从 git 迁到 svn ，我真是日了 doge 了。。。

[msg7086]

#13 @zioc 你以为别人是为了什么才从 svn 换到 git 的？

[zioc]

@msg7086 都说了，没办法 公司的产品是全端，甚至包括 asha 、展讯、黑莓、 mtk 。。。都在 svn 。


@Phariel
@perpyy
@wizardoz
@Menng
...

[zioc]

@PINK0FLOYD 这个想过，麻烦

[msg7086]

@zioc 人们抛弃 SVN 就是因为分支反人类啊。

[yhxx]

好神奇。。。竟然从 git 迁移到 SVN 。。。。

[LINAICAI]

从 git 迁移到 SVN
＋ 10086

[xuxanwan]

....git --> svn 你这是倒着走啊

[lightening]

不能用 git-svn 吗？

[ChanneW]

自己试过方案 1 ，感觉 trunk 不好。
当前的公司方案 2 ， tag 作为发布，和 git 用的流程差不多。

[ostholz]

很多大公司的代码管理是比较拖后的。 这个是也没有办法的事儿。

[JobsLong]

有个工具好像叫做： git-svn 可以互相转换

[billlee]

公司 SVN 还能怎么用，当 FTP 用啊

[jhdxr]

这么多无意义的吐槽也真是醉了。。。虽然。。。我也想吐槽。。。

之前在阿里用的接近模式 2 ，每次任务基于 trunk 新开一个分支，上线的时候合并回 trunk 。
至于 LZ 你所提到的情况， svn 也是有分支合并功能的啊！！！

[ibcker]

@ifconfig 你口味好重···

[FrankFang128]

svn 很难用，你只用 update 和 commit 两个功能就好啦 ~~~

[Tedko]

你用 git svn 之类的工具好了 n 。开发时候还是用 git

[incompatible]

这帖子噪音真大。


我之前所在团队的做法：

- 严禁直接在 trunk 上开发
- 每个 feature 的开发启动后，从 trunk copy 至新的 branch ，在 branch 上开发、提测、测试
- 基于 branch 机制，可以同时有多个 feature 并行开发
- 测试通过后把 branch merge 至 trunk （此时的 trunk 可能已经被合并了其它 branch 的代码，跟当初 copy 至此 branch 时已经不一样了，所以需要回归测试）。此时锁定 trunk ，不允许任何 merge 或 copy from 。在 trunk 做回归测试
- 回归测试通过后，把 trunk copy 至 tag ，使用 tag 打包、部署上线。解锁 trunk
- 当线上代码发现 bug 时，依然是通过开新的 branch 来解决 bug 具体流程同上
- 如果某个 branch 的开发时间非常非常长，在它开发结束时， trunk 上可能已经被 merge 了好多 branch 。这时为了降低把 branch merge 回 trunk 时解决冲突需要的时间以及回归测试的成本，会采用先把 trunk merge 至 branch 、先在 branch 上回归测试的方式

[Wangxf]

svn 几乎 0 学习成本，下载个小乌龟就行了

[forcecharlie]

@zioc 查看 svn merge 命令，也可以获得 修改的 diff 然后 trunk 合并。