On 14/06/12 19:03, Ian Dickinson wrote:
On 14/06/12 18:42, Stephen Allen wrote:
Personally,
I'd love to remove and svn ignore em, but I think other developers use
them :)
It has been discussed in the past. Personally, I'd be happy to lose
them. One argument has been that having a shared set of compiler
settings (via .settings) means that there's some common policy on which
compiler warnings are consistently addressed. We could fix that via a
shared findbugs or checkstyle configuration (& a commitment to use the
tool!)
Another argument has been that it's easier to get up and running quickly
from checking out the source tree. That, however, could be solved by
'mvn eclipse:eclipse', assuming the user doesn't mind installing maven
(easy on linux, less so on windows afaik) and waiting for it to download
the Internet the first time it runs.
The third reason to not get rid of .classpath is that it's currently how
the command line apps instantiate the classpath when invoking tools in
the development version. See bin/jena_path and bin/tdb_path.
So: solvable problems, but there are costs involved.
I understand the arguments for keeping them but is there a solution to
do some local equivalent of svn:ignore?
Whatever kicking to mvn/m2e I do to get Jena projects to work touches at
least the .classpath. Which means my local copy diverges. So to check
anything in I have to make sure to exclude those dot files from the
checkin. I can do that manually each time if I'm careful but it's a
problem waiting to happen. I can't svn:ignore them because the ignore
would presumably then propagate to the shared repository.
Does anyone have a work around?
Dave
