我对版本控制比较陌生,到目前为止只有使用TortoiseSVN / VisualSVN使用Subversion的经验。我一直在阅读其他类型的VCS(git,mercurial等),并且我正在考虑尝试它们 - 但是,许多支持或反对特定VCS的论据似乎主要归结为主观偏好,所以我'我可能会给每个人看一看。
在考虑这样做时,我想知道在理论上是否可以在单个代码库上使用多个VCS。哪些(如果有的话)VCS组合可能是这种可能性?如果可能的话,会有多少后勤噩梦试图兼顾各自的排除名单?
这样做的一个可能的理由可能是备份冗余。一些VCS提供程序(Beanstalk,Github,Bitbucket)提供了一个免费存储库,因此您可以在几个不同的地方免费备份相同的repo。
答案 0 :(得分:10)
当然,这是可能的,在某些情况下甚至是常见的。例如,git
和svn
是一个自然对。标准用例是一个组织,由于各种原因必须拥有遗留的中央Subversion存储库,但开发人员希望使用Git来提高它所提供的生产力。
输入git-svn
。现在,开发人员从他们自己的本地Git存储库推送到中央Subversion存储库,但仍然获得了Git的所有强大功能。这个过程对Subversion存储库完全透明,只看到推送到它的更改。
答案 1 :(得分:5)
Mercurial(使用hgsubversion),git(使用git-svn)和bzr(bzr-svn)都可以选择与上游svn存储库同步。
因此,已经可以(假设扩展能够运行良好)与具有不同SCM的svn存储库进行交互。
答案 2 :(得分:1)
在一个代码库上处理多个VCS通常很困难(但并非不可能)。但是,您可能会遇到删除文件的问题......有时,一个VC无法识别文件已被删除。
但是,我不建议这样做。大多数VC使用代码库中的文件来跟踪更改。拥有多个VC系统会污染您的文件系统,其中包含大量可能导致其他VC出现问题的文件。
答案 3 :(得分:1)
当我读到你的问题时,我的第一反应是“当然,技术上可行,但确实是一个非常糟糕的主意。”
在看到其他评论之后我会稍微回顾一下。好的,每个用户都可以拥有一个与中央存储库分开的本地存储库,并使用它来基本保持检查点的工作。在这种情况下,它们可能是完全独立的VCS,并不重要。
但是,如果你想要两个不同的VCS同时持有你的中央存储库,这在技术上是可能的,但是一个非常糟糕的主意。 VCS的重点在于您保留了对文件所做的所有更改的历史记录,您可以看到在何时进行了哪些更改以及 - 如果用户对提交包含中途体面评论 - 为什么。如果拥有2007年6月19日版本的客户遇到问题,您可以完全按照2007年6月19日存在的代码检索代码,因此您正在调试用户实际运行的代码。如果您发现最新的更改是一个很大的错误,您可以回滚。等等。
但是如果你有两个存储库......你是否会同时执行与两个存储库相同的提交?至少那是一堆额外的工作。在最坏的情况下,迟早有人会犯错误,忘记承诺一个或不提交,直到第二天,在其他人进行干预提交后,存储库将不会真正相同。或者你要交替,有时检查A,有时退出B?但是,没有人会知道其中任何一个是什么。
我可以看到使用两种不同的VCS几天或几周只是试一试,看看它们是如何工作的,感受一下你更喜欢哪种。但即便如此,我也不会那样做我的生产系统。我有真正的制作VCS,然后是我们玩的另一面,但没有人认为是权威的。
答案 4 :(得分:0)
我知道它不是很多使用多个VCS,但有些VCS可能有不同的前端。例如,Git可以有一个SVN前端,这样SVN客户端就可以使用Git存储库(而且它们不是Git的明智者)。我认为还有其他可用的前端。
答案 5 :(得分:0)
当然可以这样做。我使用git-svn更新我的本地git存储库并提交到公司的svn存储库。使用您将决定使用的任何VCS工具,您最有可能遇到的问题是在使用远程存储库中的更改更新本地存储库期间。
如果您使用bazaar作为本地存储库,the most problematic thing就是当您的本地市集库存在分歧并且您想要提交到远程存储库时。 有时你必须做“push overwrite”来解决它。
当使用git-svn使用远程svn存储库中的更改来更新本地git存储库时,我没有遇到这种“分歧存储库问题”。但有时当我做“git svn rebase”它会产生冲突,如果没有做正确解决它的程序,你可以花很多时间。因为我一遍又一遍地遇到这个,我有documented it,现在我觉得它不是很重要。