bazaar performance with single large project and a comparison with?git / mercurial

[Russ Brown]

Stephen J. Turnbull wrote:
> Torsten Bronger writes:
> 
>  > > This would be ameliorated greatly by a Darcs-style hunk-by-hunk
>  > > commit front-end, though.
>  > 
>  > Do you mean a Bazaar process in daemon mode?
> 
> No.  When you do "darcs record", darcs goes into an interactive mode
> where you can choose which hunks will be recorded as part of the
> patch.  So suppose while you were adding a new feature, you also
> notice a couple of typos in comments which should have fixes pushed to
> mainline immediately.  In darcs, you fix them immediately, then you
> record one patch which excludes those hunks, then you record a second
> patch which includes *only* those hunks.
> 

I raised this for equivalent functionality in bzr-gtk:

https://bugs.launchpad.net/bzr-gtk/+bug/185764

svk also supports this via the commit command's --interactive switch.

> In git, I approximate this by committing as soon as I see the
> unrelated typo, then committing the typo fix, then cleaning things up
> ex-post by cherrypicking.  (My apologies to Stefan ... I really
> oughtta have this hooked into diff-mode somehow! :-)
> 

In git I do it using git-gui, which makes it trivial. Though it would be 
nice to have an even greater granularity than hunk level and allow 
individual lines to be included/excluded from the commit. Sometimes a 
hunk encompasses things you want and don't want. Bug #185764 has that 
idea noted too...

> I find that mode of work painful in Mercurial because of the
> 500-1000ms delay for the commit.  I assume that bzr would be similar
> because of the overhead of starting up the Python interpreter.
> 
>