I've not had time to setup to try it as you've asked. I do not
anticipate having any time soon. Perhaps someone else on the list can
try it and comment.
Mark
On Mon, Dec 1, 2008 at 10:53 AM, Andrei Ivanov <andrei.ivanov_at_gmail.com> wrote:
> 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
>
>
--
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-12-01 16:57:18 CET