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

Re: Request change to fix Checkout As ... behavior

From: <clm_lists_at_mac.com>
Date: 2005-09-02 18:02:35 CEST

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

>> 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.

Received on Sat Sep 3 02:02:35 2005

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.