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

How to layout folders locally and in SVN when using eclipse

提问by Lena Schimmel

I've been working with eclipse and SVN for many years in teams from a single developer up to 12 and I always was the one to setup our folder structure. I managed to get it working somehow, but I feel that my folder layout is far from optimal. It's hard to tell what my typical folder layout looked like, because it looked very different each time.

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

I'm just starting another big project now, and I want to do it the professional waythis time.

我现在刚刚开始另一个大项目，这次我想以专业的方式来做。

Facts about the project

关于项目的事实

Those are the facts right now:

这些是现在的事实：

• All developers will work with Eclipse
• Some will be using Subclipse to integrate SVN into Eclipse, others will use external clients like Tortoise SVN or svnX
• we're developing on Windows and Mac OS
• we're using ant to automate building and junit testing
• there will be multiple interrelated projects:
  • a library written in pure java, so it runs on all known java platforms
  • several applications for several java plattforms (J2SE, J2ME, android...). All those applications depend on the library mentioned before

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

What to do with .project?

.project 怎么办？

I'm alway unsure wether to commit those files generated by eclipse (like ''.project'' and ''.classpath''). In prior projects, sometimes we put them into the SVN, sometimes we didn't, and both approaches had ther pros and cons. Once, we even committed the whole workspace, but that seemed to be a bad idea.

我总是不确定是否提交由 eclipse 生成的那些文件（如“.project”和“.classpath”）。在之前的项目中，有时我们将它们放入 SVN，有时我们没有，两种方法各有利弊。有一次，我们甚至提交了整个工作区，但这似乎是个坏主意。

One key concept that I'm certainly missing is how Eclipse handles its workspace. By default, the whole project lies inside the workspace-folder, but there can be projects that are external, which are linked in some magic manner I just don't understand.

我肯定缺少的一个关键概念是 Eclipse 如何处理其工作区。默认情况下，整个项目位于工作区文件夹内，但可以有外部项目，它们以某种我不明白的神奇方式链接。

Possible folder layouts

可能的文件夹布局

I'm unsure how to layout the project locally andon the repository. I think there are three possibilities:

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

• the workspace is a subfolder of my local working copy (like c:\code\myWorkingCopies\projectXyz\trunk\workspace)
• my workspace IS my working copy (I use c:\code\myWorkingCopies\projectXyz\trunk\ as workspace)
• My workspace is somewhere (c:\code\workspace) and my working copy somewhere else (c:\code\myWorkingCopies\projectXyz\trunk) and I have those external projects
• any other ideas?

• 工作区是我本地工作副本的子文件夹（如 c:\code\myWorkingCopies\projectXyz\trunk\workspace）
• 我的工作区是我的工作副本（我使用 c:\code\myWorkingCopies\projectXyz\trunk\ 作为工作区）
• 我的工作区在某个地方 (c:\code\workspace) 和我的工作副本在其他地方 (c:\code\myWorkingCopies\projectXyz\trunk) 并且我有那些外部项目
• 还有其他想法吗？

What kind of answer am I looking for?

我在寻找什么样的答案？

A dummy folder structure, maybe something like that (do I just answer my own question?):

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

• trunk
  • projects
    • projectA
    • projectB

• 树干
  • 项目
    • 项目A
    • 项目B

Along with a hint what to checkout where, like that:

连同提示在何处结帐，如下所示：

• checkout trunk/projects to c:\code...)

• 将主干/项目结帐到 c:\code...)

And some guidlines like

还有一些指导方针，比如

• never upload files of type x,y,z...

• 从不上传 x、y、z 类型的文件...

回答by Ickster

Workspaces and repositories shouldn't be related.

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

The workspace is really just where Eclipse stores a bunch of settings. Project files can (and usually do) live in the workspace, but as you know, they can be imported from an external source--the import is just a logical link.

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

You can create as many workspaces as you want for specific purposes; you could even import projects in one workspace into another if you had reason to do so.

您可以为特定目的创建任意数量的工作区；如果您有理由这样做，您甚至可以将一个工作区中的项目导入到另一个工作区。

The SVN layout should be separate from how your workspace is defined. They may end up looking similar, but that shouldn't imply that they're actually the same. I'd recommend each Eclipse project have its own SVN project, so that instead of having

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

• http://myrepo
  • myworkspace
    • trunk
      • projectA
      • projectB
    • tags
    • branches

• http://myrepo
  • 我的工作区
    • 树干
      • 项目A
      • 项目B
    • 标签
    • 分行

you have

你有

• http://myrepo
  • projectA
    • trunk
    • tags
    • branches
  • projectB
    • trunk
    • tags
    • branches

• http://myrepo
  • 项目A
    • 树干
    • 标签
    • 分行
  • 项目B
    • 树干
    • 标签
    • 分行

What this does for you is give you the flexibility to lay out your workspace completely separate from how your repository is structured. You'll be able to check out individual projects into the workspace without having to checkout the entire codebase. You'll be able to have projects checked out on development branches while others are on the trunk, you can revert changes to one project while leaving another alone and so forth.

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

The last question about which artifacts to check into SVN is a matter of taste. I'd recommend checking in whatever artifacts are universal across the development team. If Eclipse is the standard IDE, go ahead and check in the .project and .classpath files so that a new developer will be able to checkout and build immediately. If certain plugins are universal and have config files of their own, go ahead and check those in as well. On the other hand, anything that isn't shared across the dev team should be left out of the repository.

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

Hope this helps.

希望这可以帮助。

---

---

EDIT

编辑

Further experience has taught me that the only things that should go into source control are the actual source files. Configuration and setup files should be regenerated by the developer when setting up a new project.

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

回答by larf311

We have a similar setup (Mac, Linux, and Windows users) and our folder structure is:

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

• trunk
  • code
    • projectA
    • projectB

• 树干
  • 代码
    • 项目A
    • 项目B

We do check in the .project, .settings, and .classpath files as well the code but NOT the workspaces. The real gotchas have to do with the build path. If you solve these there is no headache and no requirement as to which directory things need to be checked out in.

我们确实检查了 .project、.settings 和 .classpath 文件以及代码，但不检查工作区。真正的问题与构建路径有关。如果您解决了这些问题，就不会有头疼的问题，也不会有需要检入哪些目录的要求。

Some tips:

一些技巧：

1. If your projects reference each other make sure they reference each other using the "Projects" tab of the build path. This will keep all references to other projects relative (../projectA rather than /opt/trunk/projectA which will break other peoples projects).
2. If you have any external libraries that you reference, create user libraries and make everyone create one with the same name. We use JBoss so we make everyone create a user library called JBoss that references the jars in their local JBoss installation. This way, it doesn't matter where your JBoss is installed, as long as you have that user library, you'll be good to go. Your project will reference the user library name, but the actual user library information is local to each user.
3. Make sure everyone knows about tips number 1 and 2. The only times things get screwed up around here is when someone forgets to make references via the Project tab instead of just linking to the jar directly.

1. 如果您的项目相互引用，请确保它们使用构建路径的“项目”选项卡相互引用。这将使所有对其他项目的引用保持相对（../projectA 而不是 /opt/trunk/projectA 会破坏其他人的项目）。
2. 如果您有任何引用的外部库，请创建用户库并使每个人都创建一个同名的库。我们使用 JBoss，因此我们让每个人都创建一个名为 JBoss 的用户库，该库引用他们本地 JBoss 安装中的 jar。这样，您的 JBoss 安装在哪里并不重要，只要您拥有该用户库，就可以开始使用。您的项目将引用用户库名称，但实际的用户库信息对于每个用户都是本地的。
3. 确保每个人都知道第 1 条和第 2 条提示。唯一会在这里搞砸的情况是有人忘记通过“项目”选项卡进行引用而不是直接链接到 jar。

All this works with Eclipse SVN plugins or without.

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

回答by Adam

In both Macromedia Dreamweaver and Eclipse I've been doing the following:

在 Macromedia Dreamweaver 和 Eclipse 中，我一直在执行以下操作：

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

Each project has its own repository, and each checkout is only of the /trunk/.

每个项目都有自己的仓库，每次签出都只在/trunk/。

Note: For Eclipse, don't create a SVN Repository project, just create the "Java App" or "PHP App" project like you normally would, and use an external program to do the checkout into that folder. Eclipse will then automagically detect the .svn information and allow you to use the SVN tools, while still using the proper workspace.

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

回答by Jim T

I use, and strongly recommend the repository structure something like:

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

• Projects
  • ProjectA
    • trunk
      • java
      • html
      • docs
      • conf
• Vendor
  • junit
    • current
    • 1.1
    • 1.2

• 项目
  • 项目A
    • 树干
      • 爪哇
      • html
      • 文档
      • 配置文件
• 小贩
  • 朱尼特
    • 当前的
    • 1.1
    • 1.2

On disk use a layout like:

在磁盘上使用如下布局：

c:\dev\
   \ProjectAtrunk\
   \ProjectBbranch4\

Working this way you're branches and tags are near your trunks and you're unlikely to depend upon the structure of the projects in your repository to reference external libraries. All references to code outside the project trunk should use externals.

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

All this means that you're more likely to be able to keep the maxim that checking out trunk is all you need to be able to build your project. Shared code is kept in and managed as a separate project and referenced with externals.

所有这一切意味着您更有可能保持这样的格言，即检查主干是构建项目所需的全部内容。共享代码作为一个单独的项目保存和管理，并被外部引用。

You're more able to view changes on a project trunk and see a complete history of your project without garbage. You're less likely to have changes to your project that aren't visible when you look at your revision history on trunk.

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

When releasing, make use of stable branches and svn-merge.

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

回答by user203185

Ickster says "...but as you know, they can be imported from an external source--the import is just a logical link."

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

Actually, this is not quite true. An import performs a copy, whereas a linked resource is a link to the outside source structure. See: Linked Resourcesand Creating Linked Resources

事实上，这并不完全正确。导入执行复制，而链接资源是指向外部源结构的链接。请参阅： 链接资源和 创建链接资源

回答by jonstjohn

I recently started using Subclipse and have a method that works for me. We're working with PHP applications, so I create a new SVN project through the Eclipse project wizard, choosing to 'Checkout Projects through SVN'. I then configure that project using the project configuration wizard and select PHP as the project type. I name the project so that in my workspace I have the project name at the top-level of the project explorer.

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

I never commit anything that is created specifically for Eclipse, especially since not everybody on our team uses Eclipse. That means excluding the .project files and any other Eclipse-created files.

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

An additional benefit of using this method is that you can have more than one repository checked out into the workspace. We work with two repository locations for our project (for specific reasons that I won't go into), so this makes it easy and convenient for me to work on both 'projects' simultaneously.

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

I'm sure there are other ways to do this, but this is what I have found to be the easiest way to use Subversion and Eclipse.

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