如何在使用eclipse时在本地和SVN中布局文件夹

Question

我已经在eclipse和SVN工作多年，从一个开发人员到12人，我总是设置我们的文件夹结构。我设法让它以某种方式工作，但我觉得我的文件夹布局远非最佳。我很难说出我的典型文件夹布局是什么样的，因为每次看起来都非常不同。

我现在正在开始另一个大项目，我想这次专业方式。

关于项目的事实

现在这些都是事实：

• 所有开发人员都将使用Eclipse
• 有些人会使用Subclipse将SVN集成到Eclipse中，其他人会使用Tortoise SVN或svnX等外部客户端
• 我们正在开发Windows和Mac OS
• 我们使用ant来自动构建和进行junit测试
• 会有多个相互关联的项目：
  • 用纯java编写的库，因此它可以在所有已知的Java平台上运行
  • 几个java平台的几个应用程序（J2SE，J2ME，android ...）。所有这些应用程序都依赖于前面提到的库

如何处理.project？

我总是不确定是否提交了eclipse生成的文件（比如'.project''和''.classpath''）。在之前的项目中，有时我们将它们放入SVN，有时我们没有，这两种方法都有其优点和缺点。有一次，我们甚至承诺了整个工作区，但这似乎是一个坏主意。

我当然缺少的一个关键概念是Eclipse如何处理其工作空间。默认情况下，整个项目位于工作空间文件夹中，但可能存在外部项目，这些项目以某种神奇的方式链接，我只是不明白。

可能的文件夹布局

我不确定如何在存储库中本地布局项目和。我认为有三种可能性：

• 工作区是我本地工作副本的子文件夹（如c：\ code \ myWorkingCopies \ projectXyz \ trunk \ workspace）
• 我的工作区是我的工作副本（我使用c：\​​ code \ myWorkingCopies \ projectXyz \ trunk \ as workspace）
• 我的工作区位于某处（c：\ code \ workspace），而我的工作副本位于其他地方（c：\ code \ myWorkingCopies \ projectXyz \ trunk），我有那些外部项目
• 还有其他想法吗？

我在寻找什么样的答案？

一个虚拟文件夹结构，可能是这样的（我只回答我自己的问题吗？）：

• 躯干
  • 项目
    • 了projectA
    • 项目B

同时提示要结帐的地方，例如：

• checkout trunk / projects to c：\ code ...）

还有一些像

这样的指导

• 永远不要上传x，y，z ......类型的文件。

Answer 1

工作区和存储库不应该相关。

工作区实际上就是Eclipse存储大量设置的地方。项目文件可以（通常也可以）存在于工作区中，但是如您所知，它们可以从外部源导入 - 导入只是一个逻辑链接。

您可以根据需要为特定目的创建任意数量的工作区;如果你有理由，甚至可以将一个工作区中的项目导入另一个工作区。

SVN布局应与工作区的定义方式分开。它们最终可能看起来相似，但这并不意味着它们实际上是相同的。我建议每个Eclipse项目都有自己的SVN项目，这样就不用了

• http://myrepo
  • myworkspace
    • 躯干
      • 了projectA
      • 项目B
    • 标记
    • 分支

你有

• http://myrepo
  • 了projectA
    • 躯干
    • 标记
    • 分支
  • 项目B
    • 躯干
    • 标记
    • 分支

这对您有用，可让您灵活地将工作区布局与存储库的结构完全分开。您将能够将单个项目签出到工作区中，而无需签出整个代码库。您可以在开发分支上检查项目，而其他项目在主干上，您可以将更改还原到一个项目，同时保留另一个项目等等。

关于检查SVN的哪些工件的最后一个问题是品味问题。我建议检查开发团队中的通用工件。如果Eclipse是标准IDE，请继续检查.project和.classpath文件，以便新开发人员能够立即签出和构建。如果某些插件是通用的并且具有自己的配置文件，请继续并检查它们。另一方面，任何未在开发团队中共享的内容都应该被排除在存储库之外。

希望这有帮助。

---

修改的

进一步的经验告诉我，应该进入源代码控制的唯一事情是实际的源文件。配置和设置文件应由开发人员在设置新项目时重新生成。

Answer 2

我们有类似的设置（Mac，Linux和Windows用户），我们的文件夹结构是：

• 躯干
  • 代码
    • 了projectA
    • 项目B

我们检查.project，.settings和.classpath文件以及代码但不是工作区。真正的陷阱与构建路径有关。如果您解决这些问题，就不会有任何问题，也不需要检查哪些目录需要检查。

一些提示：

1. 如果您的项目相互引用，请确保它们使用构建路径的“项目”选项卡相互引用。这将保持对其他项目的所有引用相对（../projectA而不是/ opt / trunk / projectA将破坏其他人的项目）。
2. 如果您有任何外部库，请创建用户库并让每个人创建一个具有相同名称的库。我们使用JBoss，所以我们让每个人都创建一个名为JBoss的用户库，它引用了本地JBoss安装中的jar。这样，安装JBoss的位置并不重要，只要你有这个用户库，你就会好起来。您的项目将引用用户库名称，但实际的用户库信息对每个用户都是本地的。
3. 确保每个人都知道1号和2号提示。只有当有人忘记通过“项目”选项卡进行引用而不是直接链接到jar时，事情才会被搞砸。

所有这些都适用于Eclipse SVN插件或不使用。

Answer 3

在Macromedia Dreamweaver和Eclipse中，我一直在做以下事情：

Working folder: 
C:\Development\
    \ProjectA
    \ProjectB
    \ProjectC

每个项目都有自己的存储库，每个结帐只有/ trunk /.

注意：对于Eclipse，不要创建SVN Repository项目，只需像往常一样创建“Java App”或“PHP App”项目，并使用外部程序对该文件夹进行检出。然后，Eclipse将自动检测.svn信息，并允许您使用SVN工具，同时仍使用正确的工作区。

Answer 4

我使用，强烈推荐存储库结构，如：

• 项目
  • 项目A
    • 躯干
      • 的java
      • HTML
      • 文档
      • CONF
• 供应商
  • 的junit
    • 电流
    • 1.1
    • 1.2

在磁盘上使用如下布局：

c:\dev\
   \ProjectAtrunk\
   \ProjectBbranch4\

以这种方式工作，您的分支和标签就在您的中继附近，您不太可能依赖于存储库中项目的结构来引用外部库。对项目主干外部代码的所有引用都应使用外部。

所有这些意味着您更有可能保持检查中继线的格言是您构建项目所需的全部内容。 共享代码作为单独的项目保存和管理，并以外部引用。

您可以更轻松地查看项目主干上的更改，并查看项目的完整历史记录而无需垃圾。 当您在主干上查看修订历史记录时，您不太可能对项目进行更改。

发布时，使用稳定的分支和svn-merge。

Answer 5

Ickster说“......但是如你所知，它们可以从外部源导入 - 导入只是一个逻辑链接。”

实际上，这并不完全正确。导入执行复制，而链接资源是指向外部源结构的链接。 看到： Linked Resources 和 Creating Linked Resources

Answer 6

我最近开始使用Subclipse并且有一个适合我的方法。我们正在使用PHP应用程序，因此我通过Eclipse项目向导创建了一个新的SVN项目，选择“通过SVN Checkout Projects”。然后，我使用项目配置向导配置该项目，并选择PHP作为项目类型。我命名项目，以便在我的工作区中，我将项目名称放在项目资源管理器的顶层。

我从不提交专门为Eclipse创建的任何内容，特别是因为并非我们团队中的每个人都使用Eclipse。这意味着排除.project文件和任何其他Eclipse创建的文件。

使用此方法的另一个好处是您可以将多个存储库签出到工作区中。我们为项目使用两个存储库位置（由于特定原因我不会参与），因此这使我可以轻松方便地同时处理两个“项目”。

我确信还有其他方法可以做到这一点，但我发现这是使用Subversion和Eclipse的最简单方法。