[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Storing IDE-specific files in the SVN repository

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-03-23 11:11:04 CET

"Justin Erenkrantz" <justin@erenkrantz.com> writes:
> I have other SVN-using projects that I'm involved with that do this
> and I *hate* it. I don't know why Eclipse users feel so special that
> they *have* to commit everything that their IDE creates into the
> repository.
>
> You also realize that every person who now decides to open up SVN
> under Eclipse will get these files changed - as they aren't treated as
> read-only by Eclipse - in essence, everyone would get Mark's
> preferences when they first open up Eclipse under the CDT (or JDT for
> JavaHL) - but if they tweak the Preferences and other settings, bam -
> these files change - so folks would now get those files marked as
> changed locally. Eww. Eww. Eww. We shouldn't be committing
> tool-generated files into our repository! This is the largest problem
> in practice with these files in our projects that use this - no one
> agrees on a JVM or version of Eclipse - so the file is always getting
> tweaked unnecessarily - the end result is that we have to often
> recommend that people just ignore those files when they are modified
> and not check them in even though SVN shows them as modified. Unclean
> to n'th degree.
>
> My vote is a very very strong 'no'. -- justin

Oh, I didn't realize this part (actually, Mark may have explained it,
and I forgot).

Yuck. In that case, yeah, I'm against putting them in trunk as well.
In a dedicated directory developer-resources/ is fine; then the
problem would only affect those whom it should affect.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 23 02:11:17 2007

This is an archived mail posted to the Subversion Dev mailing list.