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

[Martitza Mendez]

On Thu, May 12, 2011 at 10:56 AM, Martin Pool <mbp at canonical.com> wrote:

> 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
>


Hi, Martin.  There is a lot to think about in your note, thanks.

I should have a good opportunity to test this within the next few days.
I'll have my stopwatch ready <grin> to take data.

~M
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20110512/03390fbd/attachment.html>