1

我正在使用带有 Subclipse 的 Eclipse 进行一些 perl 开发。Subversion 存储库的设置如下：

  • /repos /repos/dev/
  • /repos/dev/crontabs
  • /repos/dev/crontabs/script1
  • /repos/dev/crontabs/script2
  • /repos/dev/守护进程
  • /repos/dev/daemons/script3
  • /repos/dev/daemons/script4
  • /repos/dev/工具
  • /repos/dev/tools/script5
  • /repos/dev/tools/script6

在文件系统上，我将整个 /repos/dev 树在本地检查到 ~/dev 并创建了三个 Eclipse 工作区，每个工作区位于“~/dev/crontabs”、“~/dev/daemons”和“~dev /工具”。

这就是事情变得奇怪的地方。在守护进程和工具工作区中，SVN 可以正常工作。我看不到 .svn 目录，我可以在 TEAM 对话框中执行所有各种 SVN 工作（例如提交、更新、清理）。但是，SVN 不能在“crontabs”工作区中工作。.svn 目录是可见的，并且没有任何 SVN 对话框选项可用。

在所有目录中，我都可以使用命令行 SVN 工具，一切正常。

这里有更多细节。

  • Mac OS X 10.5.6
  • Eclipse 平台 - 版本：3.4.2 - 内部版本号：M20090211-1700
  • SVNKit 库 1.2.2.5405
  • SVNKit 客户端适配器 1.5.6.1
  • 子剪辑 1.4.8
  • 史诗 0.5.46

我尝试删除 deameons .metadata 和 realted .profile 文件以尝试将其清除并开始一个新的工作区，但这没有用。

任何人之前都见过这种行为和/或知道如何让 SVN 命令在所有工作区中工作，而不仅仅是其中一些？

更新：我还应该提到 /dev 目录中还有很多其他我不使用 Eclipse 的资产。因此，我将命令行 SVN 工具与 Eclipse 中的 SVN 函数结合使用。最初使用命令行工具检查了所有内容，然后我只是使用 Eclipse 进行提交。让我吃惊的是为什么它在两个子目录中工作，而不是在命令行 100% 工作的第三个子目录中工作。

4

3 回答 3

0

我不确定我是否完全遵循这一切。而且 Subclipse 插件不如 CVS 插件精致。但是，如果您将项目复制到工作区并且它包含 Subversion 上下文（.svn 文件夹），正如 Bemose 所指出的，这对 Subclipse 没有意义。

理论上，当您使用 Team/Share 并收到警告消息时，您可以批准，它会破坏现有的 .svn 文件并构建正确的新文件。如果你幸运的话，它甚至会起作用。它与 CVS 一样，但是，正如我所说，Subclipse 可能是一个更大的问题。

最好的办法是使用 Eclipse subversion 透视图和“Check out as Eclipse Project”选项将项目签出到您的工作区中。

如果您绝对需要从命令行构建项目目录，请使用 Subversion导出命令，而不是 checkout 命令。导出会省略“.svn”目录，因此 Eclipse 可以不受干扰地完成它的工作。但是，您必须执行 Team/Share 才能将导出的项目连接到 subversion 存储库。

于 2009-07-07T14:33:55.287 回答
0

当您切换工作区时，其他工作区的所有设置等都将被忽略。

与其检出整个主干并创建 3 个与您的存储库结构一致的工作区，不如创建 3 个工作区，并将存储库的相关部分检出为每个工作区的项目。

于 2009-05-06T18:43:10.713 回答
0

当您创建一个新项目并将文件导入其中时，Eclipse 不假定项目是受版本控制的。您必须使用 Project's Team -> Share Project... 对话框明确告诉它。

一旦您选择了正确的目录，Eclipse 应该会告诉您该项目已经在该位置共享，但无论如何都要在 Eclipse 中为其激活 SVN 命令。

于 2009-05-06T19:21:28.080 回答