Comment 2 for bug 193980

Aaron Bentley пишет:
> Alexander Belchenko wrote:
>> and bzr removed all empty directories and symlinks. And therefore
>> destroyed my working tree almost entirely.
>
> Revert can't tell whether it's reverting an add or a merge. All it
> knows is whether the files it's reverting were automatically generated.
> This only applies to regular files, not symlinks and directories. We
> have no way of retaining only user-modified symlinks and directories.
> If we retain all symlinks and directories, then bzr's ability to revert
> to historical revisions and to revert merges would be compromised.
>
>> I think it's inappropriate, completely wrong, stupid and ugly
> behavior.
>
> I understand that you're upset, but when you call my work stupid and
> ugly, that makes *me* upset, and then I don't want to help you.

Sorry about this.

> There is a command to do what you want: "remove --new --keep".

May be you're right. I'm used to the fact that revert safely undo
add for files, so I did mistake by running it for more complicated case.

> I actually am not sure the current behavior is inappropriate. It seems
> to me that the behavior you want is "undo", not "revert". Revert has
> been changed to try to behave more like undo for people who expect it
> to, but ultimately, it does not have enough data to do this perfectly.
> We don't have a complete record of the state prior to the change being
> undone, which is what we would need to implement "undo".
>
> And of course, symlinks and empty directories are much easier to create
> than files, so we've historically placed less importance on preserving them.

Not in the case when user have about 100 such files and symlinks.