Q: Should 'bzr remove' take as long as 'bzr commit'

[Martin Pool]

On 12 May 2011 19:49, Martitza Mendez <martitzam at gmail.com> wrote:
>
> Hi.
>
> The following all happened in Bazaar Explorer.
>
> Today I met with a situation in which a developer had accidentally committed
> about a dozen binaries, with an average size of 100 MB.  Yikes!
>
> Obviously, that ill-advised commit took a long time (5+ minutes)
>
> The remove and getting a fresh status also took a long time (5+ minutes).
>
> Does a remove need take as long as a commit?  Maybe the repo is being
> repacked after such a big change?

remove should only need to delete the files (unless you say --keep)
and update the working tree metadata.  It doesn't change the
repository and should not need to repack.

In a situation like this you will probably also want to uncommit,
which will get them out of your repository.  That should also be fast.

John has recently improved some things in remove and status but I'm
not aware of anything that would have made them take time proportional
to the size of the files you removed.  That is quite surprising.

Oh, I realized the problem may be that we're checking whether the
files are modified or not before deleting them, and that may take some
time -- though I would still be surprised if it's 5 minutes, unless
the disk is unusually slow.  It may be faster with --no-backup.

If you can reproduce this, please send us instructions on how to do
so, or file a bug.

Martin