Re: Recursively reverting files

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 cach=
e fully.

We extended the Team > Cleanup/Refresh option to do this. Try using the opt=
ion after refreshing your workspace and see if that helps.

Mark

Sent from my iPhone

On Feb 26, 2016, at 6:44 PM, Jacob Weber <[email protected]> wrote:

>> I cannot recall a single occasion in 10+ years I have had to do this.  S=
o what is the specific scenario you have where this is necessary?  Please p=
rovide more details.  How does TortoiseSVN handle the same situation?
>=20
> Haven't used TortoiseSVN. But as an example, today I deleted a bunch of p=
lugins on a Cordova project. This involved deleting several directories wit=
h 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.
>=20
> So on the first revert, it just found the directories that were deleted, =
but not their contents. So it restored them as empty directories.
>=20
> The next revert restored the contents of those empty directories, but aga=
in not the contents of their subdirectories. And so on. In this example I h=
ad to revert 7 times, most of which took several minutes.
>=20
> ---
>=20
> I just tried adding two files, one inside a directory with un-committed p=
roperty changes. When I Revert, it looks like the behavior is different wit=
h the property change; selecting the file inside the directory doesn't auto=
matically select the parent directory.
>=20
> That makes sense. So maybe you should only revert recursively if the dire=
ctory 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.
>=20
>>> On Fri, Feb 26, 2016 at 3:54 PM, Jacob Weber <jacob at jacobweber dot c=
om> wrote:
>>>=20
>>> 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 o=
ne
>>> file at a time. There's got to be a better way.
>>=20
>> I cannot recall a single occasion in 10+ years I have had to do this.  S=
o
>> what is the specific scenario you have where this is necessary?  Please
>> provide more details.  How does TortoiseSVN handle the same situation?
>>=20
>>=20
>>> I took a look at:
>>> http://subclipse.tigris.org/issues/show_bug.cgi?id=3D1303
>>>=20
>>> and I'm aware of the UI issues it mentions. But it seems like:
>>>=20
>>> - if it's going to revert each selected file individually, it could sti=
ll
>>> pass -R when reverting each one, so that if it's a directory, its conte=
nts
>>> will be reverted. This would especially help when you deleted a nested
>>> directory, and each Revert command just restores one layer of files, bu=
t
>>> not its children.
>>>=20
>>> - in the dialog, if you select all files in a directory, it could rever=
t
>>> the directory itself. The UI already makes it look like it will do this=
, by
>>> checking the directory when you check its files.
>>=20
>>=20
>> The main issue with reverting a directory is we have to be careful to no=
t
>> 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 reve=
rt
>> the content changes in all files beneath the folder too.
>>=20
>> If the folder is scheduled-add, then it should be safe to revert it
>> recursively since you cannot revert the folder without the children anyw=
ay.
>>=20
>> --=20
>> Thanks
>>=20
>> Mark Phippard
>> http://markphip.blogspot.com/
>=20
> ------------------------------------------------------
> http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=3D1047&dsMessageI=
d=3D3163136
>=20
> To unsubscribe from this discussion, e-mail: [users-unsubscribe@subclipse=
.tigris.org].

------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=3D1047&dsMessageId=
=3D3163138

To unsubscribe from this discussion, e-mail: [[email protected]=
igris.org].