代码之家 › 专栏 › 技术社区 › Dandikas

分布式源代码管理不适用于Visual Studio用户?[关闭]

mercurial open-source git svn visual-studio

Dandikas · 技术社区 · 14 年前

我记得SVN历史上的两个事件:TortoiseSVN可用,VisualVN可用。

第一个结果是:“我们永远不想在命令行中使用SVN”。第二个结果是:“没有VisualVN,我们永远不会使用SVN和MSV。”

请理解这个正确的-如果我们需要一些乌龟不能完成的东西,我们使用SVN命令行;如果我们需要的东西不能从MSV获得,我们使用乌龟。但除此之外(99.9%的时间),您所需要的就是掌握在IDE中。

现在我确实理解并喜欢分布式源代码管理的好处,但是我根本没有办法搜索在IDE中重命名的文件,并手动执行hg rename以避免丢失历史记录(“delete+create new”而不是“rename”=no history)。我也不认为责备或文件还原是不能直接对解决方案资源管理器中选择的文件执行或打开进行编辑的操作。有了VisualVN,所有这些,还有更多的,都能正常工作!

DSCM的概念性好处是很好的,但是如果简单的话,它们就不好了,IDE中没有日常使用的功能!

问题是:是否有一个带有插件的分布式源代码管理像VisualVN那样平滑地集成到MSV中? Git扩展和VisualHg目前还没有接近这一点,VisualVN团队拒绝使用以下内容创建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.A必须从IDE:

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

不是很多吗?

更新:

1)测试 HgSccPackage 昨天。它确实有更多需要的特性可以从IDE中获得,并且它们尊重当前的上下文,例如选择/打开文件等。不幸的是,它的解决方案树状态当前是错误的,不支持文件夹状态。

2) Git Source Control Provider 在回复中提及,与 VisualHG 缺少至少两件事:

出于某种原因,他们有少量的上下文操作(例如,责备/注释是不适用的)
它们都牢固地基于MSV源代码控制API(与VisualVN不同),因此不提供解决方案文件夹状态(与 HGSCC包装 )。

3) Charles Bailey 指出,那 Git处理重命名 不管怎样。是的,是的。这里不需要任何IDE支持(不确定Mercurial)。因此,Git MSV支持只缺少良好的上下文、一键操作和适当的树状态支持(好吧,还有一条黄线,但我们可以说它是非常好的,但目前不是必须的)。

7 回复 | 直到 14 年前

Hibri 14 年前

我发现了git的vs集成是毫无意义的。您唯一需要与Git交互的时间是准备、提交和推送到远程存储库。

当您完成编码,代码编译并通过测试等时,这就完成了。现在我通过命令行或tortisegit使用git。

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

我们已经在我的公司使用Git和Tortisegit几个月了,即使是VisualVN用户也不会错过。

Henk 14 年前

关于用于GitExtensions的Visual Studio集成。”我们“没有添加您正在寻找的集成,因为它不适合Git工作流。由于没有文件锁定或重命名问题,所以在提交更改之前,您可以忘记源代码管理。

这就是说:有一个Visual Studio插件可以满足您的要求。你可以在这里找到它: http://visualstudiogallery.msdn.microsoft.com/en-us/63a7e40d-4d71-4fbb-a23b-d262124b8f4c 此Visual Studio插件将Git和Git扩展的源代码管理提供程序添加到Visual Studio中。

我不确定TortoiseGit,但是作为Fas和GitExtensions,没有为Visual Studio添加源代码管理提供程序的计划。这不是一个技术或时间问题,它已经构建在“SCC”分支中。Visual Studio使用的工作流与典型的DVC使用的工作流完全不同。如果您发现源代码管理提供程序非常重要,那么最好还是使用SVN,因为这可能更适合您的工作流。

Ton Plomp 14 年前

你看过吗 VisualHG 作为Visual Studio for Mercurial的插件?
我不是Visual Studio用户,因此无法对功能发表评论。

Visionary Software Solutions 14 年前

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

Dandikas 14 年前

我的回答是:不。

花2周时间研究和测试各种工具和插件。履历:在撰写本文的时候,没有一个单独的免费分布式源代码控制能像SVN和VisualSVN那样平滑地集成到MSV中。

SVN不是分布式的,VisualVN也不是免费的,这就是为什么我在寻找不同的东西。

对我来说,两周的研究并不是一个小调查,这是我发表这个答案的唯一原因——希望它对其他“处于变化边缘”的人有用。

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

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

pablo 14 年前

好吧,这正是我们试图用塑料单片机解决的问题。虽然它不仅适用于“Windows用户”,实际上也不适用于“Visual Studio”,但我们必须承认vstudio是这里的主要IDE。 http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

user1115652 14 年前

这听起来像是把事情颠倒过来,但我就是这样做的。我使用C++。我在Eclipse中编写代码,在vs.Eclipse中编译和调试 plugin 对于吉特来说,如果我没有错的话,它或多或少会做你所期望的事情。(不可否认,我不是所有人,我也从未使用过注释)如果不是,它是开源的,所以你可以做得更好!

对于两个不同的项目,您必须制作两个项目并跟踪include等,但是作为一个附加的好处,您不仅具有git集成,而且具有更好的大纲和语法突出显示、一键代码导航和后退按钮等。vs的一些方面更好,但它们都是小问题,我相信EclipseCDT会随着时间的推移而改进。