On Sat, Nov 15, 2008 at 8:03 AM, Andrei Ivanov <andrei.ivanov_at_gmail.com> wrote:
>> I would checkout again for starters. To be sure my working copy was
>> valid. You could create the folder and move it using the Repository
>> view. Then Eclipse could not get in the way of the operation. An
>> update would then pull in those changes to your working copy.
>>
>> I cannot think of any reason this should not work locally, but it
>> sounds like your working copy might have some problems in it.
>>
>> Before moving folders it is a very good idea to do Team > Update on
>> your Project so that it is updated to HEAD revision and is not a mixed
>> revision working copy. These things should not mess up the move
>> itself, but they can get in the way of committing the move.
>>
>
> It seems I cannot reproduce this on a new workspace and a fresh
> checked out project...
> I did manage to reproduce other problems:
> After successfully moving some directories, I tried undo and it
> failed, saying the resource already exists.
If you are literally using Undo then I doubt we have any way to handle
that for you. You should use Subversion's "Revert" which is how it
would do an Undo.
> The initial moved directories seem to disapear only after I commit the
> changes so Eclipse seems to be right.
When you delete a folder in Subversion it exists in your working copy
until you commit it. This is because the folder has to contain the
".svn" folder which has the metadata and folder contents. The SVN
working copy is in the process of being redesigned for a future
release. I think it would make the behavior of stuff like this a lot
nicer as these sort of things would not need to be carried forward.
> Then... in a java project, I try to rename a package and it fails:
> java.lang.IllegalArgumentException: Element not found:
> /eservicesq/eservicesq-model/src/main/java/qa/ict/model/eservicesq/.svn.
> at org.eclipse.core.internal.watson.ElementTree.elementNotFound(ElementTree.java:255)
This looks real similar to the original problem. I suspect something
is being corrupted in your working copy. Maybe when you do Undo some
parts of your WC are put back before the previous error occurs. Just
speculating.
> Another problem:
> In the 'Team Synchronizing' view, I'm using the 'Show Change Sets'
> button. When it is active, sometimes the incoming changes are
> invisible.
> If I deactivate it, the incoming changes become visible.
Sometimes switching to Outgoing and back can also make a difference.
> Another problem:
> Because the package renaming fails, I've created the new
> 'qa.ict.eservicesq.ws.service' package and moved the contents of the
> 'qa.ict.eservicesq.portal.service.ws' package in it.
> Then I deleted the package which would translate in deleting 3
> directories, qa/ict/eservicesq/portal/service/ws,
> qa/ict/eservicesq/portal/service and qa/ict/eservicesq/portal.
I do not think we have any way to be Java-aware here. We are
ultimately told by Eclipse that you deleted a folder and we run svn
delete for that folder.
> I have selected the changes(both the creation and the deletion) and
> commited, just to see that the new directories and files were
> commited, but only the leaf package/directory
> was deleted qa/ict/eservicesq/portal/service/ws
>
> When switching back to the 'Java perspective', the remaining package,
> qa.ict.eservicesq.portal.service wasn't marked as deleted anymore so I
> had to delete it by hand.
> Now, 2 directories would have to be deleted, 'portal/service' and then 'portal'.
> When trying to commit the deletion, it said that the item is out of
> date, even though no one else has commited anything.
> After resynchronizing, an incoming change appeared, for
> eservices-ws/src/main/java/qa/ict/eservicesq/portal/service, marked as
> conflicting, but which contained nothing.
> After updating, I could commit, but again, only the 'service'
> directory was deleted... the remaining 'portal' dir was again not
> marked for deletion any more, and I had to do all those steps again.
You cannot delete a folder unless it is at the HEAD revision in the
working copy. Folder revisions become out of date on every commit.
This is what Subversion calls a "mixed revision working copy". It is
described in the book and elsewhere. The short answer is that Yes,
you will always need to do an update before you can commit the delete
or move of a folder. Even if you are the only user using the
repository.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-11-16 17:19:12 CET