我刚才在脑子里想到了这个古怪（愚蠢？）的想法，我想在同一时间用Git和Subversion跟踪同一个文件夹（项目）;即文件夹/项目将包含.svn和.git目录。
我在搜索中没有发现任何相关信息，所以这就是为什么我在这里抛出这个想法来评估它的优点和缺点（如果有的话）。我可能正在寻找的是：为什么不能或不应该使用这种策略？
问：我为什么要这样做？
我们已经在网络上有一个Subversion repo，有超过1年的历史记录+ svn：externals +链接到bug跟踪+钩子。但我希望拥有DVCS的灵活性，例如Git，这样我们就不必连接到网络来承诺我们的工作;这样我们也可以远程工作。
问：但我可以使用git svn！
不幸的是，Git svn不支持svn：externals。并且git子模块与svn：externals不同。
问：这种组合可以实现什么目标？
Git的灵活性：代码可以在本地编辑和提交，而无需连接到网络;此外，将回购推广到生产或登台服务器或同事将是一件小事。
SVN的集中和外部回购利用：有效利用SVN：外部，我们将为自己节省大量工作，然后开发人员已经熟悉SVN。
理想情况下，我想最终完全切换到Git，但是现在，因为svn：externals使得集成外部回购非常容易，保持颠覆完整是有道理的。
答案 0 :(得分：5)
这个策略绝对有用;我已经习惯了，虽然相当简短，我知道我公司的其他开发人员已经使用了更长时间。但这并不意味着它很容易。
你会发现你需要做很多工作才能让Subversion和Git保持同步。举个简单的例子：当你执行svn update时，你还需要做一个git commit -a或类似的事情，否则Git会认为你的工作副本有很多变化，Subversion知道这些变化是-date with remote repository。
如果您需要svn update -r出于某种原因查看旧版本，或尝试使用svn switch等，这会变得更加复杂。
根据您是否有Git跟踪您的.svn目录，您将遇到其他问题。如果你不这样做（即你将.svn放在.gitignore文件或类似文件中），你会发现使用Git的分支功能要困难得多。请考虑以下工作流程：
svn up和git commit，以便获得最新代码，修复错误，git commit和svn commit。或者，您可以让Git跟踪.svn目录。这避免了上述问题 - 当您在步骤3再次检出功能分支时，您还会检查此时的Subversion元数据，因此Subversion知道所有内容都是基于的正确修订。
可悲的是，Subversion从未被设计成以这种方式使用。在Subversion 1.6（我不知道1.7）中，.svn目录可能包含重要的空文件夹。 Git不跟踪空文件夹，因此这些可能会在Git操作之间丢失，从而破坏Subversion工作副本。我知道有一位开发人员编写了一堆脚本来修复这些错误的.svn目录，但这并非易事，而且非常脆弱。
答案 1 :(得分：1)
我认为您不会遇到任何冲突，但您的SVN存储库不会包含GIT存储库的提交。
示例：
离线时，开发人员在GIT中使用描述性提交消息执行5次提交 现在，SVN重新上线，他希望将更改保存到SVN。他现在或者用一个描述性较差的消息进行一次提交，或者他必须通过将他的工作副本重置为那些特定的提交并将它们中的每一个提交给SVN来重复他对git的提交。
答案 2 :(得分：1)
Git和Svn可以很容易地存在于目录中。在.gitignore中忽略所有.svn目录，在svn ignore .git目录中。我以前用过它，直到我意识到我不再需要SVN了。