• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Do you store IDE-specific files in your repository?

 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi ,

In Continuous Integration , The author state that

"You must put everything required for a build in the source control system, however you may also put other stuff that people generally work with in there too. IDE configurations are good to put in there because that way it's easy for people to share the same IDE setups."



This is quite contradict with my personal believe that IDE-specific configurations shouldn't be check-in to source repository. Doesn't it mean that team members have no freedom in choosing their IDE? Even they agree to use the same IDE, how can you manage the compatibility of IDE configuration files across various versions. Different team members may prefer different version of the IDE. Even with the same version, the IDE configuration files are very easy to get modified by all sort of actions. Do all those changes should be check-in to the repository?

I am re-organizing my repository so I am interested to know whether you keep your IDE-specific files in your repository. If you do, please share with me how you deal with the above problems.

Thanks very much
 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes we do.

We have had several fairly complicated applications and found it easier to check everything into version control and enforce a standard operating environment than trying to debug different build configurations.

There are ways to provide a middleground, such as using 'variables' in Eclipse, but again it is easier to install Java, ant, Tomcat in same location on each machine. IMO.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Our whole team is using Eclipse, and we check in all the configuration files. That way when someone changes a build path, everyone else gets it updated automatically.

I don't remember any problems with different version of Eclipse.
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Of course, this only works if everyone is using the same IDE.
 
chatchai chailuecha
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks very much for all replies. I have to admit I am quite surprise with all the replies above. I thought we developers are a kind of creature who doesn't like to work under a restricted environment.

I agree that it will make setting up project in IDE easier but the IDE-specific configuration files are very easy to be intentionally/accidentally modified e.g. you install a plug-in that add/change project configuration or you create a new compiler profile to point to a newest JDK to test if a bug has been fixed in that JDK version or you create a new server runtime profile to try testing your product on Glassfish. How do you prevent team members to check-in this kind of changes to repository?

Thanks vermuch
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by chatchai chailuecha:
I thought we developers are a kind of creature who doesn't like to work under a restricted environment.



We are also quite lazy, and don't like to do things manually that could happen automatically. Having necessary changes automatically reflected in all workspaces is quite attractive to us.

the IDE-specific configuration files are very easy to be intentionally/accidentally modified e.g. you install a plug-in that add/change project configuration or you create a new compiler profile to point to a newest JDK to test if a bug has been fixed in that JDK version or you create a new server runtime profile to try testing your product on Glassfish. How do you prevent team members to check-in this kind of changes to repository?



*I* don't prevent that. When these things happen, as they do from time to time, we sit together and decide how to best deal with it. We are a team, after all.
[ April 07, 2008: Message edited by: Ilja Preuss ]
 
chatchai chailuecha
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks very much for all replies.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are 2 parts of the IDE environment (well, sometimes 3).

One part is invariant. It defines the basic shape of the project and how it gets built. In Eclipse, this is the .project and .classpath files. In IntelliJ, it's the XML project files excluding the IWS file. These I check into version control.

In Eclipse, the user's current view of the IDE is stored external to the project, so it can't be checked in. In IntelliJ, it's the IWS file, and I put it in the CVS file exclusion list. The user's current view is not only meaningless to any other user, it can actually damage their IDE in some cases, since it's more closely tied to the user's own computer configuration.

There's also often some sort of metadata that may be stored in various ways and locations (such as XML schema catalogs, run/test configurations or common JAR libraries). When it needs to be shared, ideally there's going to be a way to share it, even if it means exporting it from the IDE into some sort of shared-resource project. Ideal and real, however, aren't always the same, so sometimes each user has to build their own.
 
Greenhorn
Posts: 4
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my project we're generating Eclipse project files on the fly based on our regular AND build.xml using a custom ANT target. That way we could just make another target to generate IDEA or Netbeans projects if we wanted.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic