My recollection is that this is all a known issue since the new SVN working copy format was introduced. When you make changes outside Eclipse and then Refresh we do not get all of the notifications we need to refresh our cache fully.
We extended the Team > Cleanup/Refresh option to do this. Try using the option after refreshing your workspace and see if that helps.
Mark
Sent from my iPhone
On Feb 26, 2016, at 6:44 PM, Jacob Weber <jacob_at_jacobweber.com> wrote:
>> I cannot recall a single occasion in 10+ years I have had to do this. So what is the specific scenario you have where this is necessary? Please provide more details. How does TortoiseSVN handle the same situation?
>
> Haven't used TortoiseSVN. But as an example, today I deleted a bunch of plugins on a Cordova project. This involved deleting several directories with many levels of subdirectories. One thing that might be important here is that the files were deleted using a command-line tool, outside of Eclipse, then refreshed inside Eclipse.
>
> So on the first revert, it just found the directories that were deleted, but not their contents. So it restored them as empty directories.
>
> The next revert restored the contents of those empty directories, but again not the contents of their subdirectories. And so on. In this example I had to revert 7 times, most of which took several minutes.
>
> ---
>
> I just tried adding two files, one inside a directory with un-committed property changes. When I Revert, it looks like the behavior is different with the property change; selecting the file inside the directory doesn't automatically select the parent directory.
>
> That makes sense. So maybe you should only revert recursively if the directory AND all of its contents are checked? That way you wouldn't revert the contents of a directory when you're just trying to revert its property.
>
>>> On Fri, Feb 26, 2016 at 3:54 PM, Jacob Weber <jacob at jacobweber dot com> wrote:
>>>
>>> Reverting a bit change in Subclipse is kind of a nightmare -- you have to
>>> go through several rounds of Team > Revert, each one slowly reverting one
>>> file at a time. There's got to be a better way.
>>
>> I cannot recall a single occasion in 10+ years I have had to do this. So
>> what is the specific scenario you have where this is necessary? Please
>> provide more details. How does TortoiseSVN handle the same situation?
>>
>>
>>> I took a look at:
>>> http://subclipse.tigris.org/issues/show_bug.cgi?id=1303
>>>
>>> and I'm aware of the UI issues it mentions. But it seems like:
>>>
>>> - if it's going to revert each selected file individually, it could still
>>> pass -R when reverting each one, so that if it's a directory, its contents
>>> will be reverted. This would especially help when you deleted a nested
>>> directory, and each Revert command just restores one layer of files, but
>>> not its children.
>>>
>>> - in the dialog, if you select all files in a directory, it could revert
>>> the directory itself. The UI already makes it look like it will do this, by
>>> checking the directory when you check its files.
>>
>>
>> The main issue with reverting a directory is we have to be careful to not
>> inadvertently revert the children when that is not desired. For example if
>> you are reverting a property change on a folder, but do not want to revert
>> the content changes in all files beneath the folder too.
>>
>> If the folder is scheduled-add, then it should be safe to revert it
>> recursively since you cannot revert the folder without the children anyway.
>>
>> --
>> Thanks
>>
>> Mark Phippard
>> http://markphip.blogspot.com/
>
> ------------------------------------------------------
> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3163136
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1047&dsMessageId=3163138
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subclipse.tigris.org].
Received on 2016-02-27 01:24:15 CET