哪些Eclipse文件适合置于源代码管理之下,显然除了源代码之外？
在我的项目中,具体来说,我想知道:
.metadata/*
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
如果有任何相关的内容,请解释您的指南.
不应在源代码管理中管理元数据.他们主要包含相关数据的工作区.
唯一的例外是.launchXML文件(启动器定义).
他们被发现
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
并且应将它们复制到项目目录中:刷新项目时,这些配置将显示在"运行配置"对话框中.
这样,那些启动参数文件也可以管理到SCM中.
(警告:在" 运行/启动/启动配置"首选项面板中取消选中"删除关联资源时删除配置"选项:通常软删除项目以便再次将其导入 - 强制重新初始化eclipse元数据.但是这个选项,如果选中,将删除你的详细启动参数!)
project-dir/.project project-dir/.classpath project-dir/.settings/*
应该在你的供应链管理(尤其是.project和.classpath根据Eclipse文档).
目标是任何人都可以签出/更新他/她的SCM工作区并将Eclipse项目导入Eclipse工作区.
为此,您希望使用链接资源仅在.classpath中使用相对路径.
注意:如果project-dir引用"外部"项目目录,而不是在eclipse工作区下创建的目录,则更好.这样,两个概念(eclipse工作区与SCM工作区)明显分开.
正如ipsquiggle在评论中提到的那样,正如我在旧答案中提到的那样,您实际上可以将启动配置直接保存为项目目录中的共享文件.然后,所有启动配置都可以像其他项目文件一样进行版本控制.
(来自博客文章提示:从KD 创建和共享启动配置)
我目前正在开发一个项目,我们在源代码管理下拥有.project和.cproject文件.我们的想法是,与库路径和链接指令相关的设置将在整个团队中传播.
在实践中它没有很好地工作,合并几乎总是回到冲突状态,需要在eclipse之外解除冲突,然后项目关闭并重新打开以使更改生效.
我不建议将它们保存在源代码管理中.
CDT配置文件对源代码控制不友好是没有价值的.有一个bug报告.cproject文件频繁更改并导致冲突,请参阅在存储库中共享cdt-project文件总是会导致冲突.
有些项目,比如那些使用Maven的项目,比如基于POM生成.project文件.
也就是说,除此之外 - .metadata不应该在源代码管理中.根据您计划管理标准的方式,您的项目必须确定projectdir/.settings是否有效.如果您可以诚实地信任您的开发人员根据标准设置他们的环境,并且您不必为任何项目定制任何特殊的环境,那么您就不需要将它们放入.我,我建议专门配置每个项目.这允许开发人员在同一工作区中处理多个项目的内容,而无需来回更改默认设置,并且它使设置非常明确,覆盖其默认设置以匹配项目的标准.
只有困难的部分是确保它们都保持同步.但在大多数情况下,您可以将.settings文件从项目复制到项目.如果您在源代码管理中有任何特别不需要的内容,请执行相应的设置svn:ignore,如果您的SCM支持它.
.classpath文件绝对是检查scm的一个很好的候选者,因为手动设置可能需要很多工作,并且新开发人员很难进入项目.确实可以从其他来源生成,在这种情况下,您将检查其他来源.
至于.settings,它取决于设置.这是一个灰色区域,但是一些设置几乎是强制性的,并且能够检查项目,在Eclipse中导入它并且设置好所有内容都很方便.
因此,在我们的项目中,我们维护了一个名为CVS.settings的.settings文件夹的副本,我们有一个ant任务将它复制到.settings.从CVS获取项目时,可以调用"eclipsify"ant任务将默认设置复制到新的.settings文件夹.配置项目开发人员所需的设置时,将这些设置合并回CVS.settings文件夹并将其提交给CVS.这样,在SCM中保存设置成为一个有意识的过程.它确实需要开发人员在签入大的更改时不时将这些设置合并到他们的.settings文件夹中.但这是一个非常简单的系统.
京公网安备 11010802040832号 | 京ICP备19059560号-6 