我对版本控制比较新，目前只有使用TortoiseSVN / VisualSVN的Subversion经验。我一直在阅读其他类型的VCS（git、mercurial等），考虑尝试它们 - 但是，支持或反对特定VCS的许多论点似乎主要取决于主观偏好，因此我可能会尝试每种。
考虑到这一点，我想知道是否理论上可能在单个代码库上使用多个VCS。哪些（如果有）VCS组合可能具有这种可能性？如果可能，尝试管理各自的排除列表会有多大的后勤问题？
这样做的一个可能的论点是备份冗余性。几个VCS提供商（Beanstalk、Github、Bitbucket）提供一个免费存储库，因此您可以在几个不同的地方免费备份相同的存储库。
当然，这是可能的，有些情况下甚至很普遍。例如，git和svn在此方面是一对天然搭档。标准用例是某个组织必须出于种种原因保留一个传统的中央Subversion仓库，但开发人员想要使用Git来提高生产力。
这时就可以用到git-svn了。现在，开发者们从他们本地的Git仓库向中央Subversion仓库推送和拉取代码，但仍然可以享受Git带来的所有好处。这个过程完全透明，对Subversion仓库来说只是看到提交上来的变更。
Mercurial（使用hgsubversion），git（使用git-svn）和bzr（bzr-svn）都有一个选项可以与上游svn存储库同步。
因此，已经可以使用不同的SCM（假设扩展功能足够好）与svn存储库交互。
通常在一个代码库上处理多个版本控制系统是困难的（但不是不可能的）。然而，您可能会遇到删除文件的问题...有时，一个版本控制系统将无法意识到文件已被删除。
然而，我不建议这样做。大多数版本控制系统使用代码库中的文件来跟踪更改。使用多个版本控制系统会在文件系统中污染大量文件，可能会导致其他版本控制系统出现问题。
当我看到你的问题时，我的第一反应是：“当然，从技术上讲是可能的，但这是一个非常糟糕的想法。”
在看到其他评论后，我稍微改变了我的看法。好吧，每个用户都可以拥有一个本地仓库，与中央仓库分开，并使用它来保持检查点。在这种情况下，它们可以是完全独立的版本控制系统，这并不重要。
但是，如果您想同时使用两个不同的版本控制系统来持有您的中央仓库，那么从技术上讲是可能的，但这是一个非常糟糕的想法。版本控制系统的整个目的是维护所有文件更改的历史记录，以便您可以查看何时进行了哪些更改，以及（如果用户在提交时包含了相当不错的注释）为什么进行了更改。如果某个客户端使用的是2007年6月19日的版本，并且出现了问题，您可以恢复代码，就像它在2007年6月19日存在的那样，因此您正在调试实际运行的代码。如果您发现最新更改是一个大错误，您可以回滚。等等。
但是如果你有两个代码库...你会对两个代码库进行完全相同的提交吗？至少这是额外的工作。最糟糕的是，迟早有人会犯错误，忘记提交一个或者在其他人做了介入性提交后直到第二天才提交，这样代码库就不会真正相同。或者你会轮流使用A和B，有时从A签出，有时从B签出？但是这样，没有人会知道其中任何一个的内容。
我可以看到在几天或几周内使用两个不同的版本控制系统只是为了尝试它们并了解它们的工作方式，感受一下哪个更好。但即使如此，我也不会将其用作我的生产系统。我会有真正的生产版本控制系统，然后在旁边放置另一个我们玩耍但没有人认为是权威的版本控制系统。
我知道这不完全是使用多个版本控制系统，但某些版本控制系统可以有不同的前端。例如，Git可以有一个SVN前端，以便SVN客户端可以使用Git存储库（他们将不知道它是Git）。我认为还有其他可用的前端。
这是完全可能的。我使用git-svn更新我的本地git仓库并提交到公司svn仓库。无论您决定使用哪个版本控制工具，您最有可能遇到的问题是在将远程仓库的更改更新到本地仓库时遇到的问题。
如果您使用bazaar作为本地仓库，最棘手的问题是当您的本地bazaar仓库分叉并且您想要提交到远程仓库时。 有时您必须执行“强制推送”来解决它。
当我使用git-svn将更改从远程svn仓库更新到本地git仓库时，我没有遇到过这种“分叉仓库问题”。但是有时候，当我执行“git svn rebase”时会出现冲突，如果不正确地执行解决程序，您可能会花费很多时间。因为我一次又一次地遇到了这个问题，所以我已经记录下来，现在我觉得这并不是什么大问题。
