我只是想到了这个古怪(愚蠢？)的想法,我想在同一时间用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使得集成外部回购非常容易,保持颠覆完整是有道理的.
这个策略绝对有用; 我已经习惯了,虽然相当简短,我知道我公司的其他开发人员已经使用了更长时间.然而,这并不意味着它很容易.
您会发现需要做很多工作才能使Subversion和Git保持同步.举个简单的例子:当你这样做时svn update,你也需要做一个git commit -a或者类似的事情,否则Git会认为你的工作副本有一大堆变化,Subversion知道它们与远程存储库是最新的.
如果您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目录,但这并不简单,而且非常脆弱.
| 归档时间： |
|
| 查看次数： |
1646 次 |
| 最近记录： |