revert after add destroy my working tree

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

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.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHvY4J0F+nu1YWqI0RAp+FAJ0Xr2ZN5AAbP4F375fVcH777GnEbgCgh85j
IzTP77j1GxXz5/igaEO+UyI=
=oltl
-----END PGP SIGNATURE-----

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.

I see bug #87548 marked as Invalid. My situation is the same.