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

[Subclipse-users] Copy and paste of folder problem

From: DM Smith <dmsmith555_at_yahoo.com>
Date: 2006-01-21 00:39:49 CET

I am wondering what is the best way to copy a directory from one project
to another such that it can then be added to that project's source code
control. In Eclipse, I have set up per project "Java Compiler" settings.
This creates a .settings folder with a couple of files in it. Because I
want the same settings for a new project, I want to copy the folder from
the one project to the other. Also, these projects are not in the same
SVN repository.

Using Ctrl-C and Ctrl-V works very badly as it also copies the .svn
directory and leaves Subclipse very confused. More on that in a bit.

I then tried copying the directory from the command line and then
deleting all the .svn directories I could find. I had to do a refresh to
make Eclipse see it.

Then I tried Export, and while that works, it does so outside of
Eclipse. Again, a refresh is in order.

Traditional Ctrl-C and Ctrl-V qualifies as a "don't do that". The
following is not a bug or a real problem, but description of Subclipse's
interaction with this "don't do that". And I guess, at the end I suggest
that improvements can be made. I think it should be possible to recover
using Subclipse.

When I do a copy and paste of the .settings directory from one project
to another, it shows up as being in the repository, when in fact it is
not. When I look in the repository via SVN Repository Explorer, it
correctly shows that it is not present. If I try a commit on the
project, it declares that nothing was changed. If I make a simple change
to any other file and commit the project only that change shows up.

When I try to delete the pasted .settings directory, it disappears from
view and it is scheduled for deletion in SVN. The project folder is
decorated with a "*" showing that something was modified. If I do a
revert on the project, it does nothing. If I hit refresh, the folder
shows up decorated with an "X" showing it is marked for deletion. If I
try to revert the project again, nothing happens.

Now, if I revert the .settings folder, I get the following error:
revert -N C:/JSword/common-swing/.settings
    Reverted C:/JSword/common-swing/.settings
revert -N C:/JSword/common-swing/.settings/org.eclipse.jdt.core.prefs
    svn: Error restoring text for
'C:\JSword\common-swing\.settings\org.eclipse.jdt.core.prefs'

When I look into the .settings folder it is empty. The other file did
not make it back either.

I can delete the .settings folder again and it won't go away.

I tried svn clean, but it didn't help.

My only solution is to go to the OS and manually delete the .settings
directory or to use the DeferFileDelete property.

I'm not sure what the right behavior should be, but I think should be
able to do the delete from within Eclipse with Subclipse as it comes
"out of the box"

In this instance I wanted to be able to get at the .svn directory within
Eclipse to delete it, but it is filtered from view and I don't see an
option for it in the filter menu of the java perspective. I guess I am
suggesting that the .svn directory appear on the Java Perspective's
Filter View list as a separate entry. Yes it is dangerous, but then
again, I can always get to it from the file system.

Doesn't the .svn directory hold some knowledge what it is connected to
that could be used invalidate or remove the .svn directory so that the
copy would work? So when an operation is started on an element could it
be checked against the .svn and if found in error, offer solutions for
the user to pick from?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Sat Jan 21 00:39:56 2006

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.