With eclipse at least, this limitation can be easily worked around.

Anything that uses a machine-specific path (or whatever else that may be machine specific) is referenced to by a variable that each developer can set on their machine. What gets committed only has references to those variables, so as long as there is some documentation on what they need to be set to, there is no problem. This is how we do our internal projects.

That being said, I'm not sure having IDE specific stuff is right for something like Struts.

Matt


David Graham wrote:
Thanks for changing the subject line so I noticed this thread again.

I am very much against keeping IDE specific files in the repository.  Even
if you're using the same IDE, no two developer's environment will be the
same so paths will be wrong, etc.  This will be painful because checking
out the code will corrupt my Eclipse .project and .classpath files.

We will end up with many IDE files in the repository none of which work
for anyone except the last person who committed them.

David

--- Mike Kienenberger <[EMAIL PROTECTED]> wrote:


Martin Cooper <[EMAIL PROTECTED]> wrote:

Other issues with keeping Eclipse files in our repo:

1) The expectation would be that they would be kept up to date. If a
particular committer doesn't use Eclipse, I don't think it's fair to
expect them to keep Eclipse config files up to date when they make
changes elsewhere.

In the cayenne project, the .classpath and .project files are stored in /cayenne/contrib/ide/eclipse/. If you want to use them, you just copy
them into your root project directory first.


At least under Eclipse, these files don't change very frequently
(.classpath when project dependency changes, .project never changes.).


If you don't use a particular editor, you don't need to mess with them. Let the people using that particular editor update them. It's the same
thing that's going to happen even if the config files are not in the repo. The only difference is that it gives a starting point (and will generally be


up-to-date for a particular editor if active committers are using it).

-Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







__________________________________ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more.
http://info.mail.yahoo.com/mail_250


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to