从ClearCase到Mercurial再到Subversion。我应该担心吗?

向后移动 将 使Subversion看起来有点原始,但它通常很容易使用和健壮,如果不是功能丰富的话。我认为,从Mercurial这样的现代DVCS转向Subversion(“CVS done‘right’”)之间最大的区别在于Subversion使用文件系统作为一切的类比:

• 在Subversion中,您可以“分支”,将所有文件从“trunk”目录复制到“branchs”中的新目录中。
• 同样,要“标记”一个修订,您可以将所有文件从“trunk”复制到“tags”目录中。

这些操作不是 真正地 标记或分支,但“标记”和“分支”目录按惯例命名。

您还必须更加小心,因为提交任何更改都会将其推送到主回购协议中供所有人查看。一个偶然的行为会让每个人的“后备箱”破裂,导致不愉快的情况。

另外,当您必须通过网络执行所有操作时,请做好慢操作的准备。

很像clearcase——svn的许多乐趣或痛苦不是工具本身,而是实现(或缺乏)。开箱即用的clearcase实际上是不可用的,有一大群聪明的人来管理它,建立整个过程,它从一文不值变成了疯狂的昂贵和轻微的创伤。

你上svn就没事了。你会想念hg的,但你应该能把你的工作做得小题大做。如果你不-责怪主持节目的人,而不是工具。

一些svn管理员使用钩子来防止来自不支持svn:mergeinfo属性的客户端的提交,git和hg连接器在这些实现中不起作用。 不是说mergeinfo那么有用。。。如果你不能指望它在那里,那就完全没有价值了。

经过多年的Subversion和Mercurial的合作,我的主要区别在于分支。我不想再去颠覆,我会怀念的。

但是毕竟你可以在你的本地磁盘上使用Mercurial(甚至在Subversion存储库的签出目录中),也许在不久的将来你可以说服合适的人,然后太阳会再次照耀。。。

尝试 hgsubversion 作为一个客户机,这将至少允许您做自己的实验分支、本地提交、shelve和其他一些不错的Hg特性。

但是,有时我在导入大型存储库时遇到了困难,在这种情况下,我会切换到 hgsvn 在subversion工作副本上使用“hg importsvn——仅限本地”。它需要一个svn客户机。我建议 Slik SVN .

这两种工具都允许您返回svn repo,但它们的操作方式有所不同。

我不得不承认,我更经常使用hgsvn,尽管我更喜欢hgsubversion的概念。进口过程还不够可靠。

在分布式源代码版本控制(DSVC)世界(git/mercurial/et al)和CSVC(centralized…)之间,对于哪个更好,存在不同的意见。

有些类似于DSVC的本地签入方法,但只将“工作”代码推送到中央/主存储库。

有些类似于所有提交的CSVC方法对每个人都是立即可见的,但是中央存储库中的代码可能并不总是工作的。

最终,这个选择是个人的,我不会太在意它,尽管我会说,我认为DSVC对更大的团队更有效,而且对于持续的集成设置也可能更好。但是,正如您总是可以用任何语言编写COBOL一样,对于源代码管理,您也可以让它按照您想要的方式工作,集中化或分布式。

你更关心的是什么是公司文化?他们是否接受svn回购协议可以随时中断,或要求svn回购协议始终有效?在我看来,这是你是否会保持理智的最大界限。

有一个svn hg连接器。

我在目前的公司使用Clearcase,并将我的细粒度提交保存在hg repo中。