将Eclipse项目文件与源文件包含在SCM中是一个很好的做法吗？ [英] Is it a good practice to include Eclipse project files in with sources in SCM?
问题描述
然而，这已经是源代码过去的问题，因为有时这些文件被意外修改和检查...从而导致其他开发人员的问题。随着M2E的出现及其对配置器的新支持，可帮助您在导入时设置Eclipse项目，我们正在重新思考这一策略。
通常，项目包括这些Eclipse文件在Subversion / Git / etc中？
顶级答案：这完全是一个味道： - ）
个人而言，对于内部项目（您对其他开发人员的环境有一定的控制权），我 do 包括Eclipse文件，并提供您需要的警告确保每个人都在配置中使用相对路径。 （每隔几个月我们就会建立一个破解，因为一个图书馆的路径是硬编码的，需要几秒钟的时间来修复，但很烦人。）我也经常使用诸如Eclipse代码格式化和编译器警告设置，使生活更轻松（例如，没有巨大的Subversion签到，因为有人的编辑们在格式化选项卡上进行了争斗）。
作为一个奖励，当你带来一个新的开发人员，当它检测到您的中继/分支中的.project文件时，Eclipse Subversion检出系统将自动配置该项目。如果您使用Eclipse来管理您的构建（相对于Ant或Make），这是一个双赢。
如果您在一个更加多样化的团队例如：使用Eclipse不是均匀的（sic？）），在实践中它们不是太多的滋扰。我有一个协作项目，我的工作有一个文件夹充满了MicroSoft Visual Studio控制文件和一个.project文件，它们必须保持同步的ad-hoc，但至少有只有两个集的那些文件进行同步。没有他们在Subversion，将有一个开发人员...
我听说过使用一个虚拟项目来保存项目文件，以及。例如
svn：//someplace.nn/projects/MyProject/trunk - > source
svn：//someplace.nn/projects/MyProject.control/trunk - >项目控制文件
我见过的唯一一个地方是在一个拥有大型GPL分支的项目中，一个非GPL本地专有插件的小型存储库... GPL分支没有.project文件，因为大多数Net协作者不使用Eclipse，项目文件位于内部（专用）Subversion服务器上，第三个项目包含专有的插件代码。 （和艺术的第四，音乐的第五个...）
We have a rather complicated multi-module Maven project. There are Flex modules, GWT modules, Java modules, and a number of WAR modules. In order to simply the process of importing these projects into Eclipse, historically we have included all the relevant Eclipse project files in the source tree.
However, this has been a source of problems in the past because sometimes those files are modified accidently and checked in...thus causing problems for other developers. With the advent of M2E and its new support for configurators to help set up Eclipse projects upon import, we are rethinking this strategy.
In general, do projects include these Eclipse files in Subversion/Git/etc?
Top level answer: That's totally a matter of taste :-)
Personally, for "internal" projects (you have some control over the other developers' environments), I do include the Eclipse files, with the caveat that you have to be sure everyone uses relative paths in their configurations. (Every few months we'd have a build break because a library path was hard-coded. It took seconds to fix, but was annoying.) I also have typically made a lot of use of things like Eclipse code-formatting and compiler warnings settings to make life easier (e.g. no huge Subversion check-ins because someone's editors got into a fight over formatting tabs).
As a bonus, when you bring on a new developer, the Eclipse Subversion check-out system will auto-configure the project when it detects the .project files in your trunk/branch. This is a double Win if you use Eclipse to manage your build (as opposed to, say, Ant or Make).
If you're on a more diverse team (e.g.: not homogenously(sic?) using Eclipse), they aren't "much" of a nuisance, in practice. I have one "collaborative" project that I work on that has a folder full of MicroSoft Visual Studio control files and a .project file, and they have to be kept in sync ad-hoc, but at least there are "only two" sets of those files to sync up. Without them in Subversion, there would be one-per-developer…
I've heard of using a "dummy project" to hold project files, as well. e.g.
svn://someplace.nn/projects/MyProject/trunk —> source
svn://someplace.nn/projects/MyProject.control/trunk —> project control files
The only place I've seen that was in a project with a large GPL branch and a small repository of non-GPL local, proprietary plug-ins … the GPL branch didn't have .project files, as most of the 'Net collaborators were not using Eclipse, the project files were on the internal (private) Subversion server, and a third project contained the proprietary plug-in code. (And a fourth for art, a fifth for music…)
这篇关于将Eclipse项目文件与源文件包含在SCM中是一个很好的做法吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
