blocks|key|1345276|text|当然，这是可能的，甚至在某些情况下是司空见惯的。例如，git和svn是这方面的天然组合。标准用例是这样一个组织，由于各种原因，它必须有一个遗留的中央Subversion存储库，但其中的开发人员希望使用Git来提高生产力。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1345277|输入git-svn。现在，开发人员从他们自己的本地Git代码库推拉到中央Subversion代码库，但仍然获得了Git的所有酷功能。这个过程对Subversion存储库是完全透明的，它只看到推送到它的更改。|1345278|entityMap|0|LINK|mutability|MUTABLE|url|http://git-scm.com/docs/git-svn^0|R|3|V|3|0|2|7|2|7|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@$9|Q|A|R|B|C]|$9|S|A|T|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|U|8|@$9|V|A|W|B|C]]|D|@$9|X|A|Y|1|Z]]|E|$]]|$1|H|3|-4|5|6|7|10|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]]]

Certainly, this is possible, even commonplace in some cases. For example, <code>git</code> and <code>svn</code> are a natural pair for this. The standard use case is an organization which must have a legacy central Subversion repository for various reasons, but in which the developers want to use Git for the productivity boost it provides.

Enter <a href="http://git-scm.com/docs/git-svn" rel="noreferrer"><code>git-svn</code></a>. Now the developers push and pull from their own local Git repos to the central Subversion repository, but still get all the cool power of Git. This process is completely and totally transparent to the Subversion repository, which simply sees the changes that get pushed to it.

blocks|key|4561746|text|Mercurial+(带有hgsubversion)、git+(带有git-+svn+)和bzr+(bzr-svn)都有一个与上游svn存储库同步的选项。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4561747|因此，已经可以(假设扩展功能足够好)与具有不同SCM的svn存储库进行交互。|4561748|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Mercurial (with hgsubversion), git (with git-svn) and bzr (bzr-svn) all have an option to synchronize with an upstream svn repository.

So it's already possible (assuming the extensions work well enough) to interact with an svn repository with differents SCM.

blocks|key|4561600|text|在一个代码库上处理多个VCS通常是困难的(但并非不可能)。但是，您可能会遇到删除文件的问题...有时，一个VC不会意识到文件已被删除。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4561601|但是，我不推荐这样做。大多数VC使用代码库中的文件来跟踪更改。使用多个VC系统会用大量的文件污染您的文件系统，这可能会导致其他VC出现问题。|4561602|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

It's usually difficult (but not impossible) to handle multiple VCS on one codebase. However, you'll potentially run into problems with deletion of files... Sometimes, one VC will not realize a file has been deleted.

However, I don't recommend this. Most VC use files within the codebase to track changes. Having multiple VC systems in place will pollute your file system with lots of files that will potentially cause issues in the other VCs.

blocks|key|1535878|text|当我读到你的问题时，我的第一反应是，“当然，技术上是可行的，但这是一个非常非常糟糕的想法。”|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1535879|在看到其他评论后，我会稍微走回头路。好的，每个用户都可以有一个独立于中央存储库的本地存储库，并使用它来基本上在他工作时保留检查点。在这种情况下，它们可以是完全独立的VCS，这无关紧要。|1535880|但是，如果您正在考虑两个不同的VCS同时持有您的中央存储库，这在技术上是可能的，但这是一个非常非常糟糕的想法。VCS的全部意义在于，您可以维护对文件所做的所有更改的历史记录，这样您就可以看到在什么时候进行了哪些更改，以及--如果用户在提交时包含了一些像样的评论--为什么。如果拥有2007年6月19日版本的客户遇到问题，您可以检索与2007年6月19日完全相同的代码，因此您正在调试用户实际正在运行的代码。如果您发现最新的更改是一个大错误，您可以回滚。等等。|1535881|但是如果你有两个仓库...您是否打算对两个存储库执行相同的每次提交？至少这是一堆额外的工作。在最坏的情况下，迟早有人会犯错误，忘记提交一个，或者直到另一个人进行了干预提交后的第二天才提交，并且存储库将不会真正相同。或者你打算交替进行，有时从A结帐，有时结帐B？但这样就没人知道里面装的是什么了。|1535882|我可以看到使用两个不同的VCS几天或几个星期，只是为了试一试，看看它们是如何工作的，得到一个你更喜欢的感觉。但即便如此，作为我的生产系统，我也不会这么做。我会有真正的生产VCS，然后另一个在一边，我们玩，但没有人认为是权威的。|1535883|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

My first response when I read your question was, "Sure, technically possible, but a really really bad idea."

I'll backtrack a little after seeing the other comments. Okay, each user could have a local repository separate from the central repository, and use this to basically keep checkpoints as he works. In that case they could be completely separate VCSs and it wouldn't matter.

But if you're thinking of two different VCSs simultaneously holding your central repository, that's techincally possible, but a really really bad idea. The whole point of a VCS is that you maintain a history of all the changes made to the files, that you can see what changes were made when and -- if users include half-way decent comments on commits -- why. If a customer who has the June 19, 2007 version has a problem, you can retrieve the code exactly as it existed on June 19, 2007, so you're debugging the code that the user is actually running. If you discover that the latest change was a big mistake you can roll back. Etc etc.

But if you have two repositories ... Are you going to do every commit identically to both repositories? At the least that's a bunch of extra work. At worst, sooner or later somebody is going to make a mistake, forget to commit to one or not commit until the next day after someone else had made an intervening commit, and the repositories won't really be identical. Or are you going to alternate, sometimes checking out of A and sometimes out of B? But then no one will ever know what's in either one.

I could see using two different VCSs for a few days or a few weeks just to try them out and see how they work, get a feel for which you like better. But even at that, I wouldn't do that as my production system. I'd have the real production VCS, and then the other one on the side that we play with but nobody treats as authoritative.

blocks|key|236032|text|我知道使用多个VCS不是很好，但有些VCS有不同的前端是可能的。例如，Git可以有一个SVN前端，这样SVN客户端就可以使用Git存储库(他们不会知道Git就是Git)。我认为还有其他的前端可用。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|236033|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

I know it's not quite using multiple VCSs, but it's possible for some VCSs to have different front ends. Git, for example, can have an SVN front end so that SVN clients can use the Git repository (and they'll be none the wiser that it's Git). I think there are also other front ends available for it.

blocks|key|1537865|text|当然，这样做是可能的。我使用git-svn更新本地git存储库并提交到公司svn存储库。对于您决定使用的任何VCS工具，您最有可能遇到的问题是在使用来自远程存储库的更改更新本地存储库的过程中。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1537866|如果您将bazaar用于本地存储库，则当您的本地bazaar存储库分散，并且您想要提交到远程存储库时，就会出现the+most+problematic+thing。有时你不得不做“推覆写”来解决它。|offset|length|1537867|在使用git-svn使用来自远程svn存储库的更改更新本地git存储库时，我没有遇到这种“不同的存储库问题”。但有时当我做"git+svn+rebase“时，它会有冲突，如果没有做正确的过程来解决它，你可能会花费很多时间。因为我一次又一次地遇到这个问题，所以我有documented+it，现在我觉得这没什么大不了的。|1537868|entityMap|0|LINK|mutability|MUTABLE|url|http://mercurial.selenic.com/wiki/Bazaar|1|http://blog.scrum8.com/2009/aug/18/resolving-git-svn-rebase-conflict/^0|0|1J|Q|0|0|3N|D|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|S|8|@]|9|@$D|T|E|U|1|V]]|A|$]]|$1|F|3|G|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|H|3|-4|5|6|7|10|8|@]|9|@]|A|$]]]|I|$J|$5|K|L|M|A|$N|O]]|P|$5|K|L|M|A|$N|Q]]]]

It is certainly possible to do this. I use git-svn to update my local git repository and commit to the corporate svn repository. With any VCS tool that you will decide to use, the problem that you will most likely to encounter is during updating your local repository with the changes from the remote repository. 

If you use bazaar for your local repository, <a href="http://mercurial.selenic.com/wiki/Bazaar" rel="nofollow noreferrer">the most problematic thing</a> is when your local bazaar repository is diverged and you want to commit to your remote repository. Sometimes you have to do "push overwrite" to resolve it. 

I don't experience this "diverged repository problem" when using git-svn to update my local git repository with the changes from the remote svn repository. But sometimes when I do "git svn rebase" it will have conflicts and if not doing the procedure to resolve it the right, you can spend alot of time. Because I have encountered this over and over again, I have <a href="http://blog.scrum8.com/2009/aug/18/resolving-git-svn-rebase-conflict/" rel="nofollow noreferrer">documented it</a> and I don't find it such a big deal now.

I'm relatively new to version control, and so far only have experience working with Subversion using TortoiseSVN/VisualSVN. I've been reading about other types of VCS (git, mercurial, etc), and am considering trying them out - however, many of the arguments for or against a particular VCS seem like they largely come down to subjective preference, so I'll probably wind up giving each one a look.

In thinking about doing so, I was wondering if it was even theoretically possible to use multiple VCS on a single codebase. Which (if any) combinations of VCS might this be a possibility for? And if possible, how much of a logistical nightmare would it be trying to juggle the respective exclusion lists?

One possible argument for doing so could be backup redundancy. Several VCS providers (Beanstalk, Github, Bitbucket) offer one free repository, so you could have the same repo backed up for free in several different places.

Multiple simultaneous version control systems?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云AI代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

功能1上新10个字符

功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符功能2描述100个字符。

功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符功能2上新100个字符。

功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符功能5描述100个字符

功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符功能5上新100个字符

功能4上新

文章&问答评论现已支持表情

全新交互，全新视觉，新增快捷键、悬浮工具栏、高亮块等功能并同时优化现有功能，全面提升创作效率和体验

社区富文本编辑器全新改版！诚邀体验～ 

精选全网热门MCP server，让你的AI更好用 🚀

💥开发者 MCP广场重磅上线！

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

我对版本控制比较陌生，到目前为止只有使用TortoiseSVN/VisualSVN处理Subversion的经验。我一直在阅读其他类型的VCS (git、mercurial等)，并正在考虑尝试它们-然而，许多支持或反对特定VCS的争论似乎主要归结为主观偏好，所以我可能会给每个人看一看。在考虑这样做的时候，我想知道在理论上是否可以在一个代码库上使用多个VCS。对于哪些(如果有) VCS组合，这可能是

问多个同步版本控制系统？
EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多个同步版本控制系统？EN

回答 6

Stack Overflow用户

Stack Overflow用户

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多个同步版本控制系统？
EN