分布式源代码控制不适用于Visual Studio用户?

时间:2010-09-29 13:44:31

标签: visual-studio svn git open-source mercurial

我记得SVN历史中的2个事件:TortoiseSVN可用,VisualSVN可用。

第一个结果:“我们永远不会想要在命令行中使用SVN”。 第二个结果:“我们永远不会在没有VisualSVN的情况下使用SVN和MSVS”

请理解这一点是正确的 - 如果我们需要使用Tortoise无法实现的功能,我们会使用SVN命令行,如果MSVS无法提供我们需要的东西,我们会使用Tortoise。但除此之外(99.9%的时间),您所需要的只是掌握在IDE中。

现在我理解并喜欢分布式源代码控制的好处,但我根本无法在IDE中重命名文件并手动执行hg重命名以免丢失历史记录(“删除+创建新文件” “而不是”重命名“=没有历史记录。我也不认为责备或文件还原为无法直接在解决方案资源管理器中选择的文件上执行或打开进行编辑的操作。使用VisualSVN所有这些,以及更多,只是工作!

DSCM的概念优势很好,但如果IDE无法提供简单的日常使用功能,那么这些功能并不好!

问题:是否有一个带有插件的分布式源代码控件,它像VisualSVN一样平滑地集成到MSVS中? Git Extensions和VisualHg目前还没有接近那个点和VisualSVN团队拒绝使用:

创建VisualGit

We can consider this option only if Git changes its license from GPL to BSD/Apache style to allow derivative commercial work.

P.S。必须来自IDE:

  • 解决方案树中的文件状态。如果编辑了任何子项,则父项即文件夹/项目/解决方案被标记为已编辑。
  • 上下文更新,提交,历史记录,责备,还原为解决方案资源管理器/打开文件中的单击操作,并提供键盘快捷键!
  • 自动跟踪和处理文件重命名/拖放/新文件创建。
  • 在编辑文件中尚未提交的内容的指示符(黄线)在文件关闭并重新打开后不会消失。

不多了?

更新

1)昨天经过测试HgSccPackage。它肯定有更多所需的功能可以直接从IDE,他们确实尊重当前的上下文,即选择/打开文件等。不幸的是,它的解决方案树状态目前是错误的,不支持文件夹状态。

2)Git Source Control Provider在与VisualHG相同的回复中提到至少缺少两件事:

  • 由于某种原因,他们有少量的上下文行为(例如责备/注释是NA)
  • 它的接缝它们都是基于MSVS源代码控制API(与VisualSVN不同),因此不提供解决方案文件夹状态(与HgSccPackage相同)。

3)Charles Bailey指出,无论如何 git处理重命名。是的,确实如此。这里不需要任何IDE支持(不确定mercurial)。所以git MSVS支持只缺少良好的上下文,一键动作和正确的树状态支持(还有一条黄线,但是我们说它非常好,但目前还不是必须的。)

7 个答案:

答案 0 :(得分:3)

我发现Git的VS集成毫无意义。 您需要与Git交互的唯一时间是您想要暂存,提交和推送到远程存储库。

当你完成编码并且代码编译并通过测试等时,这就完成了...... 在这一点上,我通过命令行或TortiseGit使用git。

我喜欢Git的工作流程,允许我在不知道有源代码控制的情况下工作,只有在我需要分享我的工作或在安全点提交时才会发挥作用。

我们已经在我的公司使用Git和TortiseGit几个月了,甚至VisualSVN用户都不会错过它。

答案 1 :(得分:2)

关于GitExtensions的Visual Studio集成。 “我们”没有添加您正在寻找的集成,因为它与Git工作流程不兼容。 Sinse没有文件锁定或重命名问题,在提交更改之前,您可以忘记源代码控制。

说完了:Visual Studio有一个插件可以满足您的需求。你可以在这里找到它:http://visualstudiogallery.msdn.microsoft.com/en-us/63a7e40d-4d71-4fbb-a23b-d262124b8f4c这个Visual Studio插件为Visual Studio添加了Git和Git Extensions的源代码控制提供程序。

我不确定TortoiseGit,但是就像GitExtensions一样,没有为Visual Studio添加源代码控制提供程序的计划。这不是技术或时间问题,它已经在“scc”分支中构建。 Visual Studio使用的工作流程与典型的DVCS使用的工作流程不同。如果您发现源控制提供程序非常重要,可能最好坚持使用SVN,因为这可能更适合您的工作流程。

答案 2 :(得分:0)

您是否将VisualHG视为Mercurial的Visual Studio插件? 我不是视觉工作室的用户,所以我无法对功能发表评论。

答案 3 :(得分:0)

呃,你看过Team Foundation Server,MS支持的源代码控制工具+项目管理解决方案吗? 2K10版本相当稳固。

答案 4 :(得分:0)

我的回答:不。

花了2周时间研究和测试各种工具和插件。简历:在写作的那一刻,没有一个免费的分布式源代码控制集成到MSVS中,与SVS一样流畅,与VisualSVN一样。

SVN没有发布,VisualSVN也不是免费的,这就是我寻找不同内容的原因。

2周的研究对我来说不是一个小调查,这是我发布这个答案的唯一原因 - 希望它对那些“在变革边缘”的其他人有用。

另外请注意,我会回顾所有问题,并回答这些问题 - 每当有人证明我错了,即当有合适的工具可用时,我会删除这个答案,并将更好的答案标记为“答案” ”


P.S。未来是在分布式版本控制系统中。如果你今天必须选择一个 - 只需选择任何一个。无论如何你不会错过很多。今天我可能会选择Git。但那真的只有我。

答案 5 :(得分:0)

嗯,这实际上是我们用Plastic SCM试图解决的问题。虽然它不仅仅适用于“Windows用户”,实际上并非“仅适用于Visual Studio”,但我们承认VStudio是我们的主要IDE。 http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

答案 6 :(得分:0)

这可能听起来像颠倒过来,但这就是我这样做的方式。我用c ++。我在eclipse中编码,我在VS中编译和调试。 Eclipse有一个plugin用于Git,如果我没有误会它会或多或少地做你期望的事情。 (诚​​然,我并不是非常喜欢所有这些,我也从未使用过注释)如果不是,它是开源的,所以你可以做得更好!

你必须制作两个项目并跟踪两个不同项目的包含等,但作为一个额外的好处,你不仅有git集成,而且还有更好的大纲和语法高亮,一键单击代码导航和后退按钮等等VS的一些方面更好,但它们是小问题,我相信eclipse cdt会随着时间的推移而改善。