On Sun, Nov 16, 2008 at 6:18 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
I know that... it just looks ugly to get an exception... maybe you can
interecept the call
and just call revert instead or at least disable the undo option.
>
>> 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.
See my previous comment.
>
>> 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.
I deleted the whole project(from the disk, not just from the
workspace) and checked it out again... and the error repeats.
Maybe you should try reproducing this for yourself.
>
>> 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.
That's not very nice... clicking on various buttons until it works...
>> 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'm not asking for that...
>
>> 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.
So... I if want to delete a folder tree, like a/b/c, I have to:
- delete the whole tree
- commit the deletion, notice that only the deletion of 'c' was commited
- delete the remaing tree again
- synchronize and update a/b
- commit the deletion, notice that only the deletion of 'b' was commited
- delete the remaing tree again
- synchronize and update a
- delete the remaing tree again
- commit the deletion
Is this really normal?
---------------------------------------------------------------------
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-18 15:27:58 CET