10

I want to add a project which in this case is created in Netbeans but this question is general for most IDE's. It's simply, what should I include in my repository. For example Netbeans creates a nbproject folder, eclipse creates a .settings folder etc. should I include these in my repository, what are the advantages/disadvantages of including or not including project specific settings.

In this case it's a personal project so I don't imagine that other people will start working on it, but it would be nice to add the bare minimum of project settings so the project itself will be easy to start work on different machines.

Improve this question
4
  • Consider tools such as maven with its eclipse plugin (or other ide) for setting up the proper environment rather than including your own.
    – user40980
    Jun 19, 2013 at 19:03
  • @MichaelT I'm very sorry but I don't really follow, would you mind expanding on that?
    – Daniel Figueroa
    Jun 19, 2013 at 19:05
  • Using a build tool, and having the build tool set up the environment for the ide allows you to be assured that the setup is the same no matter what the platform (or ide). Even solo developers have multiple environments (ide vs build). This simplifies the question to one that is answered "don't check in anything that is specific to your environment because they are generated code." - the same rational that you don't check in the .java classes generated by jaxb, but rather the instructions (build.xml or .pom file) on how to build them.
    – user40980
    Jun 19, 2013 at 19:13
  • If it is "original" is must be backed up. If it changes and those need tracking and is original, it should be revision controlled. The catch - how to structure you repo so that you source remains your source, while you tool chain configurations does not pollute the source repo. Same applied to resources such as images, sound and video....
    – mattnz
    Jun 19, 2013 at 21:25

4 Answers 4

Reset to default
5

It really depends on what data it is and should be decided on a case by case basis, perhaps even for individual files. Take a look at the contents of those files. More often than not you can tell what they mean. Stuff like the position and size of the IDE's windows is something you do not want in source control.

But some of the IDE project files are vital project metadata. I don't know Netbeans well, but for eclipse, the .project file tells the IDE what the project's name is, that it's a Java web project, etc. and the .classpath file contains information about source folders and libraries. Some files in the .settings directory can be equally important, e.g. org.eclipse.core.resources.prefs contains information about what encoding should be used for which files.

As project metadata, this stuff very much deserves to be versioned in source control.

Some IDEs can import project metadata from other IDEs. It would be even better to have it in a form that is not tied to a specific IDE.

For Java, there is such a thing: Maven. It imposes strong conventions on the project's structure and allows you to specify project metadata (such as library dependencies) in one point (a file called pom.xml which is in the project's main directory and, of course, in source control). There are plugins which then create IDE project files from the Maven configuration, and others which can automate the project build process, or do just about anything. Sometimes it feels like it makes things unneccessarily complex and it takes some time to learn, but the benefits are generally worth it.

Improve this answer
2
  • 1
    if I am not wrong Maven is IDE independent. If so, then, since it contains projects settings/metadata therefore it definitely should includes in the repo, but not the "IDE project files" which OP seems to be specifically referring to.
    – Bleeding Fingers
    Jun 20, 2013 at 19:42
  • @hus787: my point is that this metadata is very much important enough to be in the repo, and while it's great when you have it in an IDE-independant form, when that is not the case it's still better to have it than not to have it.
    – Michael Borgwardt
    Jun 20, 2013 at 19:53
3

Artifacts that help your development and are of no use to the build/release or the project itself should not be included. The repo should be clean and tidy and only have those things which are relevant to the project not your environment. The repo should be incognizant of your habits. And secondly it will unnecessarily bug you when do something akin to git status ... but hey I never made any changes...ahh ignore that.

Let me give a more practical example (I'll use githere as a tool):

You would never want a (recursive)submodule inside your main repo to have an IDE specific stuff(it might interfere with main project environment as well) because all you care about is the code that was written by someone else(or you) and is of use inside the current project. Not the environment in which it was developed. You probably don't want to do that to someone else either.

To be able to use your setting on different machine I suggest digging inside your IDE and see what support it provides for such things. Emacs has init and Emacs server too. Or you could make your custom macro or script(.sh) which does the setup automatically.

Improve this answer
9
  • -1: disagree completely. This can be very important and useful information, and your repo definitely should include such information.
    – Michael Borgwardt
    Jun 19, 2013 at 21:53
  • @MichaelBorgwardt what if OP later plans on switching to some other IDE. How will those project IDE specific settings be understood in the other one? An example would be much appreciated.
    – Bleeding Fingers
    Jun 19, 2013 at 21:58
  • 1
    @AmyBlankenship that's my point its your workspace how can you be sure that it doesn't interfere other's(they pull and all of a sudden their workspace is replaced by that of yours), its better to keep those things in a separate local branch or you could use mercurial for your personal project specific workspace VC and git for the project VC. About the code templates, I think your IDE isn't mature enough(or hasn't been explored properly yet) and if your saying the templates are project specific then I guess you should be looking for patterns in your code.
    – Bleeding Fingers
    Jun 21, 2013 at 6:41
  • 1
    @AmyBlankenship think about it. If it's not specific to the project then what is it doing in the project repo in the first place? I suppose something like this would be better
    – Bleeding Fingers
    Jun 21, 2013 at 16:06
  • 1
    @AmyBlankenship the case which you are describing, I think probably has, better and more elegant alternatives then simply adding the workspace which is personal and IDE specific. And since I can't conceive a situation in which your suggestion would an appropriate, therefore I would disagree, with qualification. Period. Or you could come up with a solid example.
    – Bleeding Fingers
    Jun 21, 2013 at 18:42
2

This really depends on what kind of information you would like to have on the repository. If you want everything right down to which files you had open and were editing at the time of the commit, and you're the only one using the repository, go ahead and commit it all, but know that it may not work on another machine.

If you want to be able to share your code with other people who might not be using the same IDE, then just commit the code itself without any project specific implementation.

If you know that everyone uses the same IDE, then you can probably include anything which isn't computer specific, that is any setting files/folders for just the IDE itself, that way they can already have the ability to import the project as the IDE expects it.

Improve this answer
1

If it's a personal project, I say store the settings in source control. Personally, nothing kills my motivation more for a project than setting up a development environment again.

When more people are involved, I don't put these things in source control. On my team, we have a mix of IntelliJ, Sublime Text, and Eclipse being used. IDE files just add clutter, and result in pulling in commits to those files from other people for an IDE you don't use.

Also, your project shouldn't be dependent on the IDE anyway. A build server won't be booting up Eclipse to compile your product, so it should already be IDE-free. A more minor point: it eliminates personal organization within the project. For example, in IntelliJ I like to use many modules within our project. No one else using IntelliJ worries about this because we don't store the .iml (module) files.

If your team is using the same IDE then it's better, but then someone commits a bad .classpath entry because they used an absolute path. Now everyone using the IDE worries about it.

Sure, the downside is that there is more setup when someone checks out the project. I think it's worth it. We use Ivy for dependency management and have information on setup, dependencies, etc. Despite this up front cost, I think it's worth it to keep IDE settings out of source control.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.