On Sep 2, 2005, at 11:46 AM, Mark Phippard wrote:
> 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.
>
I mis-interpreted due to posts I read on this. I never found the
blindly deleting thing a problem since I never depend on the IDE
classpath stuff as I manage everything through Ant anyway for
portability.
>
>> 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.
>
Yes, my project has a "src" folder which matches the settings in
Eclipse to create one for a new project. The checkout fails at that
point and stops, and the Eclipse-created default source folder I
configured is there, but empty (of course).
>
>> 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.
Excellent. I added this since I did not see rebuttal emails to the
idea which intermingled with the thread about Check As ... problems.
>
>> 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.
Your suggested work-around of telling Eclipse to create folders that
do NOT match the project folders and then reconfiguring the Project
properties to point to the real source/bin folders appears to work.
Although I think I'll stick to the command-line checkout for regular
use, way fewer steps ;)
Thanks, Mark! Hit me back about the directory conflict issue and let
me know if I can help somehow.
Colin
Received on Sat Sep 3 02:02:35 2005