Eclipse中的SVN分为两个阵营。SVN的人开发了一个名为Subclipse的插件。Eclipse开发人员有一个名为subversion的插件。广义上讲,他们做的事情是一样的。它们各自的优点和缺点是什么?


当前回答

当然,这两个IDE插件都有它们的问题。但两者都不排除并行使用其他解决方案,如TortoiseSVN或命令行。我在工作中使用这三种方法。

需要记住的重要一点是,所有客户端SVN软件都应该使用相同的SVN文件格式(不同版本的SVN不同),否则就会自找麻烦。

我们发现的另一个问题是当客户端软件使用与服务器不同的SVN文件格式时。(所谓文件格式,我指的是所有信息在所有那些看似不可见的. SVN文件中表示的方式,这些文件有效地记录了SVN需要知道的关于您的项目文件的信息。)这会造成严重破坏。在1.5服务器和1.6客户端之间有一个有记录的错误,但我现在找不到链接。

由于与我们的SVN 1.5.5服务器不兼容,我们在运行高级(IMO) Subclipse 1.6插件时遇到了问题。所以我们回到了《颠覆者》。它工作得很好,尽管速度较慢并且有些bug(但正在改进)。不过,当我们的服务器更新时,我们将切换到Subclipse。是的,我们用TortoiseSVN检查我们的项目,并将它们导入Eclipse(这样更快)。

我们发现,正如其他帖子所说,如果我们运行更新版本的TortoiseSVN,在1.6中编写文件,它将不起作用。x格式,但当我们恢复到TortoiseSVN 1.5。X,它工作得很好。命令行客户端也是如此(我们在Ant任务中利用了它)。

其他回答

两者都非常相似,但是subversion是“eclipse svn提供者”。我主要使用subversion是因为它有几个方便的特性:

历史分组

当我浏览一个分支的历史记录,而不仅仅是看到每个提交的一堆行时,它可以根据今天、星期等对提交进行分组。

中继、分支和标签的映射

subversion假定默认的svn布局:trunk、分支、标签(您可以更改),因此每当您想要标记或分支时,只需单击一下,并提供标记或分支的名称。

就像我说的,这些都是我觉得方便的小区别。这两个扩展都可以很好地与mylyn一起工作,但总的来说,这两个扩展确实没有太多区别。

与subversion合并是一种痛苦(还没有尝试Subclipse),我从来没有成功合并过。合并的预览是伟大的,但它永远不会完成合并,或者它将花费很长时间。大多数时候,我通过命令行完成合并,没有任何问题。

如果你经常使用Subversion进行合并,那么你可能会更喜欢CollabNet桌面版- Eclipse版。你必须在CollabNet注册一个账户才能下载,但它是免费的。它本质上是Subclipse,具有更好的合并UI。

我没有加入CollabNet。

CollabNet已经将改进后的合并客户端提供给Subclipse的非注册用户。当从更新站点安装Subclipse时,您可以通过选择CollabNet Merge Client特性来获得它。

对于Eclipse的每个新版本,我都会安装subversion,因为它是Eclipse提供的标准。每次,它都无法识别我之前的项目。

所以我最终卸载了subversion,并安装了Subclipse,它工作得非常出色。我还经常从命令行和Eclipse中使用SVN, Subclipse在这方面没有问题。

如果您在自己的公司中使用其中的一种,甚至希望将它们捆绑到自己的基于Eclipse的产品中,那么使用Subclipse会更方便,因为它是在业务友好的Eclipse公共许可证下可用的。

另一方面,颠覆性需要所谓的连接器才能充分发挥作用。这些公司拥有不同的执照。因此,您可能会为subversion功能获得两到三个不同的许可证,而所有其他Eclipse插件都在一个EPL之下。这也是为什么这些连接器没有托管在eclipse.org上的原因。

这就是在subversion安装之后动态下载它们的原因(这也意味着仅仅镜像eclipse.org更新站点并不能在公司网络中提供可用的subversion离线安装)。

我还没有真正使用过它,但它似乎支持“检出As”,就像内置CVS支持一样。

比如,从SVN中获取一个项目,并能够将其作为一个web项目运行,人们可能能够一气呵成。但是为了在Subclipse中得到相同的结果,我只需要检查源代码并运行:

mvn eclipse:eclipse -Dwtpversion=2.0