Is there any chance I will get an answer?
On Tue, Nov 18, 2008 at 4:27 PM, Andrei Ivanov <andrei.ivanov_at_gmail.com> wrote:
> 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-12-01 16:54:07 CET