Vil*_*lx- 11 svn mercurial scalability dvcs
我们现在对SVN非常满意,但Joel的教程引起了我的兴趣.所以我想知道 - 在我们的情况下它是否可行？
问题是 - 我们的SVN存储库是巨大的.该软件本身已有15年的历史,并且已经存在于几个不同的源控制系统中.有超过68,000个修订版(更改集),源本身占用超过100MB,我甚至无法猜测整个存储库消耗了多少GB.
问题很简单 - 整个存储库的克隆可能需要很长时间才能完成,并且会在远程理智的驱动器上消耗更多的空间.而且由于分布式版本控制的重点是拥有所需数量的存储库,我开始怀疑.
Mercurial(或任何其他分布式版本控制)如何处理这个问题？或者它们无法用于如此庞大的项目？
补充:澄清 - 整个事情是一个项目的整体野兽,它编译成一个单独的.EXE,不能拆分.
补充2:第二个想法 - Linux内核存储库使用git,可能比我的大一个数量级或两个数量级.那么它们如何使它发挥作用呢？
gav*_*inb 13
大型项目的分布式版本控制 - 可行吗？
绝对!如你所知,Linux是庞大的并且使用Git. Mercurial也用于一些主要项目,例如Python,Mozilla,OpenSolaris和Java.
我们现在对SVN非常满意,但Joel的教程引起了我的兴趣.所以我想知道 - 在我们的情况下它是否可行？
是.如果你现在对Subversion感到满意,你可能没有做太多的分支和合并!
问题是 - 我们的SVN存储库是巨大的.[...]有超过68,000个修订版(变更集),源本身占用超过100MB
正如其他人所指出的那样,与许多现有项目相比,这实际上并没有那么大.
问题很简单 - 整个存储库的克隆可能需要很长时间才能完成,并且会在远程理智的驱动器上消耗更多的空间.
Git和Mercurial都非常有效地管理存储,它们的存储库占用的空间远远小于等效的Subversion存储库(已经转换了一些).一旦你有一个初步结账,你只是推动三角洲,这是非常快.它们在大多数操作中都明显更快.最初的克隆是一次性的成本,所以它需要多长时间并不重要(我打赌你会感到惊讶!).
而且由于分布式版本控制的重点是拥有所需数量的存储库,我开始怀疑.
磁盘空间很便宜.开发人员生产力更重要.那么如果回购占用1GB呢？如果你能更聪明地工作,那是值得的.
Mercurial(或任何其他分布式版本控制)如何处理这个问题？或者它们无法用于如此庞大的项目？
可能值得一读的有关使用Mercurial的项目(如Mozilla)如何管理转换过程.其中大多数都有多个回购,每个回购都包含主要成分.Mercurial和Git也都支持嵌套存储库.还有管理转换过程的工具--Mercurial内置支持从大多数其他系统导入.
补充:澄清 - 整个事情是一个项目的整体野兽,它编译成一个单独的.EXE,不能拆分.
这使得它更容易,因为您只需要一个存储库.
补充2:第二个想法 - Linux内核存储库使用git,可能比我的大一个数量级或两个数量级.那么它们如何使它发挥作用呢？
Git专为原始速度而设计.磁盘格式,有线协议,内存中算法都经过了大量优化.他们已经开发了复杂的工作流程,补丁从单个开发人员,到子系统维护人员,再到中尉,最终到Linus.DVCS的最大优点之一是它们非常灵活,可以实现各种工作流程.
我建议你阅读由Bryan O'Sullivan 撰写的关于Mercurial的优秀书籍,它可以让你快速上手.下载Mercurial并完成示例,并在一些临时回购中使用它来感受它.
然后启动convert命令以导入现有的源存储库.然后尝试进行一些本地更改,提交,分支,查看日志,使用内置Web服务器等.然后将其克隆到另一个框并推动一些更改.计算最常见的操作,并查看它的比较方式.您可以免费进行全面评估,但需要花费一些时间.
Tad*_*ski 11
100MB的源代码少于Linux内核.Linux内核2.6.33和2.6.34-rc1之间的更改日志有6604次提交.您的存储库规模对我来说听起来并不令人生畏.
两倍,但仍然花生与我们都有的大硬盘.
| 归档时间： |
|
| 查看次数： |
1993 次 |
| 最近记录： |