从 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 呢？

[leonlh]

竟然有从 git 切到 svn...

[maddot]

歪一下，不是公务员才称自己上班的地方叫单位的吗

[cangshu]

SVN 用的好反人类啊。。。。

[ifconfig]

不理解用 svn ， git 最好用的是分支，每次合并分支就好比在床上对着韩红撸了一回，爽！！

[forcecharlie]

svn 的逻辑还是第一种 好， trunk 做主开发，定期新建 branch 然后 修复 bug ，发布 在 tag, 修复也在 branch ，
包括 gcc subversion llvm reactos 这些项目使用 svn 托管都是这么做的。

[leefly]

竟然有从 git 切到 svn... [doge]

[janon]

竟然有从 git 切到 svn...

[janon]

只听过从 svn 切到 git 的。。。

[lyragosa]

别人都是 svn 切到 git ，这还有 git 切 svn 的……

[66beta]

哼哼，楼主公司不是唯一
怎么用？当网盘用最刁！

[learnshare]

居然有从 Git 迁移到 SVN ...

[zioc]

@leonlh
@leefly
@janon
@learnshare
其他的代码都在 svn ， iOS 也要迁过去...

[zioc]

@forcecharlie 我的意思是 旧版修复的内容要能更新到新版，求用法。

即 1.0.0->1.0.1 更新的内容要能更新到 2.0 的分支

[zioc]

@maddot ..

[itbdw]

竟然从 GIT 迁移到 SVN 。。。。。

[PINK0FLOYD]

把热更新的补丁开一个分支，然后分布合并到 1.0 和 2.0 中。

[kevinzhwl]

给个方案
继续用 git + 在需要的节点时把代码推到 svn 。

[Menng]

居然会从 Git 迁移到 SVN

[wizardoz]

竟然从 GIT 迁移到 SVN

[perpyy]

居然会从 Git 迁移到 SVN, 我报警了!

[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 合并。

[582033]

用 git-svn 呗，我也是从 git 换到 svn 。

[adexbn]

@582033 +1 。然而实际上最后都是 svn->git

[hpeng]

@incompatible 真特么规范！我现在公司全部在 trunk 开发…内网构建一周挂个 2 到 3 次……每次挂了的心情简直就是 doge

[newghost]

没觉得 SVN 有什么不好

[imlinhanchao]

V2 社区有一种同，当有人不同时，若他提出疑问，疑问将很难被解答，若他提出观点时，观点会被打压，若他分享时，分享的事物将被贬低。但这又有什么关系呢，任何人类社区，无论线上还是线下，都是不可避免的会朝这样的结果发展。因为，社区本来就是因为观点相似才聚在一起的呀~

[xiaoyao9933]

svn 确实有点反人类。。

[Menng]

第二种，发布时用 Git

[yuankui]

见过 svn 迁 git 的,还没见过 git 迁 svn 的

[Navee]

一大波喷子正在来袭

[kobe1941]

从 git 到 svn ，这种公司楼主你辞职算了

[bbiao]

先不吐糟楼主从 Git 迁移到 SVN 这种逆天的行为了，对于你的需求：

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

其实你提到的两种使用 SVN 的开发方式都能满足，无非就是在发布 1.0.1 版的时候，都必须在 Branch 上开发。

[zioc]

@incompatible 谢谢。很受用！
@jhdxr 谢谢分享！
@582033 @Tedko git-svn 可靠吗，是不是可以这样：本地 git ，远程 1 git ，远程 2 svn 。维持原有的 git remote 做小组内部更新（较频繁的提交），用 git-svn 每天一次提交 git 的代码到 svn

[holmesabc]

公司 svn 就只做一个仓库来用. 一个在开发的, 其它都是 tag.
反正主线 分支 tag 都是完全的文件 copy

跟 git 思想不一样, 还是不要完全搬 git 的规则的好.

就用 1 方案好了. 感觉 svn 目录切来切去很麻烦的.

[est]

切 svn 好用多了啦。开发进度没法保证，直接强制 commit 就说代码掉了，然后扯一天皮。

[Tedko]

@est hhhhh ，别忘啦 git push -f 也可以诶啊

[est]

@Tedko git 的好处是分布式的，你不小心 push -f 弄掉的，别人如果有 HEAD 可以再 push -f 回来。。。 svn 就不一样啦。没了就没了，一 update 大家都没了。而且断网大家的代码就没法同步啦。只能干瞪眼啦。特别适合制度性官僚作风开发团队。

[ttma1046]

从 git 到 svn ，这种公司楼主你辞职算了

[cnhongwei]

楼主在错误的道路上越走越远。

[9hills]

用 SVN 后就别折腾分支了， release 的时候开一个 release 分支相当于坐下 snapshot 就行了

你要是开发的时候自己折腾分支，那是自寻苦吃。。。

[Clarencep]

无论是 git 还是 svn ，都可以采用相似的流程来开发。
只是建议不要直接在 trunk 上开发，就像 git 一般不推荐直接在 master 分支开发一样，而是针对每个 feature 建立一个 branch ，然后在这个 branch 上开发测试完成后，再合到 trunk 上。
至于老版本的问题，在老版本的 tag 或 branch 上修复完后，要及时合入 trunk 就行了。

[mio4kon]

以前是第一种,现在是第二种

[loveisbug]

方案 2 。

[startry]

第一种方案。 一份代码理论上就应该保留一个发布的口, Trunk 是最好的选择。

如果在分支上发布, 那么 Trunk 不能保证是最新最稳定的, 分支上才是最稳定的。

如果使用第一种方案, 发布了 1.0 版本, 切换到分支开发下一版本, 1.0 出 bug 回 Trunk 进行修改。问题是 Trunk 有时候因为协同等原因会被破坏, 这个时候需要 tag 来恢复 Trunk （当然回滚也可以, tag 纯粹最为 bak )。保证无论何时多个部门多个团队协同不会出现太大的问题。

方案二的话需要无时无刻的把 Trunk 往分支里合并, 发布后合并进入主干, 每次需要下一个发布者承担相应的风险

[582033]

@zioc 可以的,只需要创建一个 "svn-remote" 加一个"git-remote",一个 git-svn dcommit ,一个 git push 即可

[ch3n2k]

可以用 subgit

[LINAICAI]

其实这种问题 svn 根本没法完美解决。。。

除非结合 git 或者纯 git ， svn 的分支压根就只是个目录的概念

[chemandy]

听过 git-svn 吧...

[loveminds]

@zioc 展讯和 MTK 以及高通...内核级或者驱动级的东西么

[holy_sin]

居然从 git 到 svn +1

[imbahom]

评论看的乐的不行不行的

[zonghua]

开源中国的 gitsvn 可以混在一起用，好厉害的样子

[billwang]

切，你们光见过 git svn 之流，想想我现在用的 vss 是多么奇葩，每次使用我都会发牢骚，虽然只是用来管理文档。

[leavic]

你们太在意工具链了，很多芯片公司多年来一直都是用 svn ，自己修复了 bug 验证好了再提交合并

[lenran]

@imlinhanchao 确实如此。

可以提出不同见解。但麻烦各位还是以为 V 友“释疑，解惑”为主！

发扬“人人为我，我为人人”的精神。

最后，也是最重要的，不要歪楼！

[juneszh]

不明白你们说的 svn 逆天在哪里? 什么一 update 就没有, 难道你们是直接在 svn 检出的文件夹上做本地开发的? 你们的习惯才逆天吧, 用 svn 基本上都是 svn 文件夹和本地开发文件夹分离, 用 BC 做联系的, 实际上 git 就是融合了这个步骤而已. 注重分支的当然用 git , 注重权限管理和文件保密(配置文件)的 svn 是不二之选, 那些说的 svn 是一文不值的真是醉了. 一个工具也能产生优越感.

[benatsh]

@juneszh
嗯，我也觉得有点狂热了，一个工具而已， SVN 文件夹和本地开发文件夹分离，每次自己再做一个拷贝，以前我们一大帮子人用的也是好好的。而且什么场景用什么工具就好了，什么都要拔到信仰的高度，这楼歪的。。。

[jianyunet]

聪明的程序员用 git ，真正的程序员用 svn

[lenran]

该贴已发展为 git 与 svn 的优越性探讨贴！

[jdlau]

长见识

[leefly]

/t/219512 😂

[lizheming]

@benatsh 那就问一个问题， svn 做分支操作的时候能不能不每次都要输入全部的 URL ？ 另外删除文件的时候要区分 svn rm 和 rm 我真是有点晕啊....

[BInaryTree111]

@ifconfig 和哈哈哈哈哈哈哈哈哈哈哈哈哈哈心疼

[zioc]

@loveminds 不是。是一个 app ，支持市面上大多数手机客户端。

[zioc]

@lizheming svn 没有分支概念，别想太多，你那条语句是 copy

[lizheming]

@zioc 据说新版有，不太清楚....

[loveminds]

@zioc 那为啥要分展讯 MTK 高通英特尔马维尔...不都是跑在 AOSP 平台上面么，最多分个 ARMv6/7/8 ， X86 和 MIPS 好了

[incompatible]

@leonlh
@cangshu
@ifconfig
@leefly
@janon
@learnshare
@yhxx


随意 at 了几位说从 git 切换至 svn 不可理喻的朋友
谁能给我讲讲当团队人数 100 人、模块几十个这样的规模下， git 该如何做权限控制？
（以上不是为了抬杠。我本人在大团队时一直用 clearcase 或 svn ，现在带小团队时选用了 git 。但是对团队规模和代码规模膨胀后的权限控制毫无头绪

[learnshare]

@incompatible Git 可以控制权限，自己搭建一个 Gitlab 就可以方便管理了

[ifconfig]

@incompatible 请阅 Gitolite 中 Access rule 一章，一百多人是怎么做到无痛用 SVN 的，至少 dev 和 trunk 分支合并不痛苦么？

[incompatible]

@ifconfig
不痛苦。模块拆分是一门艺术。