bzr status/commit/revert performance

John Arbash Meinel john at arbash-meinel.com
Thu Jan 10 21:47:58 GMT 2008


Joshua Jensen wrote:
> I have some behavioral questions about Bazaar 1.0 and 1.1 and
> performance.  I noticed this as I was testing performance with a very
> large .bzr repository (4 gigabytes).
> 
> When I 'bzr add', the dirstate is populated with the new filename
> information.  Then I 'bzr commit'.  Minor updates are performed to the
> dirstate, but that is all.  For the large 4 gigabyte repository, this
> takes 25 minutes.
> 
> Then I run 'bzr status' or, alternatively, I run 'bzr commit' again. 
> This takes much longer than expected, and so I run the Windows utility
> Filemon from sysinternals.com.  From Filemon, I can see Bazaar scanning
> the directory structure and reading each file in the tree in its
> entirety.  When this is done, dirstate has had its SHA1 hashes (I think)
> populated (I think).  This scan of every file takes 15 minutes.
> 
> If I run 'bzr status' or 'bzr commit' again, Bazaar just checks
> timestamps and is very fast.  For the repository above, it takes around
> 8 seconds.
> 
> So, question #1: Why does Bazaar not generate the SHA1 hashes as it is
> committing the data in the first place?  It would speed up the
> subsequent operations.

Known issue which we hope to address.


> 
> Related to all this is the performance of 'bzr revert'.  When doing a
> 'bzr add', I realized I screwed it up and added far too many files.  I
> ran the 'bzr revert' command and waited and waited and waited.  It seems
> 'bzr revert' reads the contents of every file in the add list before
> reverting it.  Bear in mind that these files have not been committed yet.
> 
> Question #2: Why does 'bzr revert', for files not yet under its control,
> not just quickly remove the filename from any .bzr internal tracking lists?
> 
> Thanks for the help!
> 
> Josh

I'm not positive about all the specifics. But 'revert' will create a
backup copy if it wants to remove a file which it thinks has unique
information in it. The idea is that if you do:

bzr merge ../other

which introduces a new file and then do

bzr revert

If you made no changes yourself, then it will just remove the file (as
repeating the 'bzr merge' should give the same contents.) If you had
edited the file, then it will create a foo.~1~ backup file.

I'm not sure why reverting a newly added file needs to check the
sha1sum, other than a possible layering issue.

John
=:->




More information about the bazaar mailing list