• 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

IDE projects and clear case version control

 
Ranch Hand
Posts: 375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I want to get comment on which of the following two options make better sense assuming someone has finished the development on his local eclipse IDE.

1) check in source code only into clear case. Don't check in any .project type file. When another developer joins team, he checks out the source codes, in his eclipse IDE, he creates a project by himself and import those source codes.

2) check in source codes and .project type files. When another developer comes, he checks out everything, then in his eclipse IDE, he can simply "import an existing project", i.e. he does not need to create a new project from scratch and add pieces.

Which way makes better sense ?

Thanks.
 
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ben,
I absolutely check in the .project files without a moments doubt. They are part of the workspace. Just like we check in build scripts. We want a new developer to get working as quickly as possible.

Eclipse lets you set variables in the workspace so you can avoid any machine specific settings from being in the .project files in the first place.
 
ben oliver
Ranch Hand
Posts: 375
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jeanne Boyarsky wrote:Ben,
I absolutely check in the .project files without a moments doubt. They are part of the workspace. Just like we check in build scripts. We want a new developer to get working as quickly as possible.

Eclipse lets you set variables in the workspace so you can avoid any machine specific settings from being in the .project files in the first place.



so the second option ? Does the first option work as well ?
 
Jeanne Boyarsky
author & internet detective
Posts: 41860
908
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

ben oliver wrote:so the second option ? Does the first option work as well ?


Yes, the second option. With the first option, you are creating manual work. That requires troubleshooting or instructions. I can't say it doesn't work, but I don't think it is a wise approach.
 
author
Posts: 5856
7
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have a few projects that use option 1 in Subversion. They are a pain to work with. I finally got tired of creating the project info each time I checked out some of those projects and I eventually checked in the .project files, thus switching the project to option 2.

Also, we use Maven, and in some cases we use relative paths to reference parent POMs, and the m2e plugin tends to display annoying warnings on some of our build settings if it cannot find the parent POM via relative path. The projects for the parent POMs used option 1 and it was a pain in the neck having to try to remember what project name to assign so that the rleative paths worked correctly. This was made worse because different projects used different relative paths for the same parent POMs (because everyone create projects using different names when checking out the parent POMs). Using option 2 avoids all of this pain.
 
reply
    Bookmark Topic Watch Topic
  • New Topic