clm_lists@mac.com wrote on 09/02/2005 11:40:22 AM:
> After reading a number of posts about this and having had no problems
> in the past with this (though it seems with each major version it
> works "less"), I thought I'd add my thoughts and request a change.
>
> To get a Java project checked out and behaving properly, I used to
> use Subclipse to do a "Checkout As..." and choose "Java Project" and
> everything worked as expected. It appears to have been changed to
> required that Eclipse-specific resources already be in a project for
> this to work, as evidenced by errors I did NOT get in previous
> versions doing this same operation:
>
> svn: File not found: revision 26, path '/trunk/.classpath'
>
> svn: File not found: revision 26, path '/trunk/classes'
These are not errors. These represent an improvement in behavior. Prior
to 0.9.33 we would have blindly deleted the .classpath file that was
created by the wizard. Now, we check if the file exists in the repository
and only delete the local file if it does exist (since checkout would fail
if we didn't). These messages are just a by product of checking to see if
the file exists.
> svn: Failed to add directory 'src': object of the same name
> already exists
This might be a problem. It sounds like the wizard created a src folder,
and you already had one in your repository, but we did not delete it? This
causes the checkout to fail. Please try to confirm this and give a
reproduction recipe as I did test this scenario. As a workaround, you can
probably just have the wizard not create that folder, then go back and
adjust the Java build properties after the checkout finishes.
> I do not agree with the opinion that you should put IDE-specific
> resources in the repo unless you have a shop which absolutely has
> everyone using the same software. (There are many clean non-IDE
> specific ways to manage classpaths, libraries, etc, and if you're
> doing nightly builds on a server you'll need to do that stuff in a
> non-IDE way anyway).
That has nothing to do with this. If anything, the intent of these
changes is to BETTER support your preferred scenario.
> Workaround right now is check out using command line, then create a
> new Java project and point to it. Not horrible, but not as clean as
> Checkout As... used to be :(
Try my other workaround. Someone else is working on a complete rewrite to
work around the limitation of the Subversion checkout.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
Received on Sat Sep 3 01:46:55 2005