[MERGE] Give commit a progress bar

Robert Collins robertc at robertcollins.net
Fri Apr 21 08:00:36 BST 2006


On Fri, 2006-04-21 at 16:49 +1000, Martin Pool wrote:
> I think this is useful but I'd really like at this point to freeze out
> any non-critical bugs so that we can get 0.8 out.  So please add this to
> a wishlist bug and keep the branch until next week when we can reopen
> for general development.

Sure.

> So +1 with comments, but not right now.
> 
> On 21 Apr 2006, Robert Collins <robertc at robertcollins.net> wrote:
> > 
> > -- 
> > GPG key available at: <http://www.robertcollins.net/keys.txt>.
> 
> > === added file 'b/bzrlib/tests/workingtree_implementations/test_commit.py'
> > +class CapturingUIFactory(ui.UIFactory):
> > +    """A UI Factory for testing - capture the updates made through it."""
> 
> Perhaps this should move (along with its selftests) to a more generic
> location, to encourage other test code to use it?
> 
> > === modified file 'a/bzrlib/commit.py'
> > --- a/bzrlib/commit.py	
> > +++ b/bzrlib/commit.py	
> > @@ -245,7 +245,12 @@
> >              self.reporter = reporter
> >  
> >          self.work_tree.lock_write()
> > +        self.pb = bzrlib.ui.ui_factory.nested_progress_bar()
> >          try:
> > +            # Cannot commit with conflicts present.
> > +            if len(self.work_tree.conflicts())>0:
> > +                raise ConflictsInTree
> > +
> >              # setup the bound branch variables as needed.
> >              self._check_bound_branch()
> 
> I'm curious - why did you move the conflict detection from below?

Bug #5798: 'conflicts in tree' check happens after commit message
editor. 

If you type in a careful email, and then get a conflict warning, it can
piss one off. I was in the area.. shrug.

>    if found_exception is not None: 
> > +            # dont do a plan raise, because the last exception may have been
> > +            # trashed, e is our sure-to-work exception even though it loses the
> > +            # full traceback. XXX: RBC 20060421 perhaps we could check the
> > +            # exc_info and if its the same one do a plain raise otherwise 
> > +            # 'raise e' as we do now.
> > +            raise e
> >  
> 
> I see this just factors out the existing code but it feels quite
> strange.  Shouldn't we just have multiple try/finally blocks, and split
> out the code if that makes it too deeply nested?

Well, its likely that it will grow further, and we have multiple places
this will be needed eventually - for instance in doCleanups [or similar]
in TestCase.tearDown(), in the multiple-unlock actions of InterFOO
classes, etc. Seems to me we should figure out the right idiom in once
place and once that is done move it to a class representing cleanups
somewhere.



> > +    def _update(self):
> > +        """Emit an update to the progress bar."""
> > +        self.pb.update("Committing", self.pb_count, self.pb_total)
> > +        self.pb_count += 1
> > +
> >      def _select_entry(self, new_ie):
> >          """Make new_ie be considered for committing."""
> >          ie = new_ie.copy()
> 
> I'd much prefer _update_pb or some such, _update is a bit generic.

sure.

>   
> > +    def clear_term(self):
> > +        """See progress.ProgressBar.clear_term()."""
> > +
> >      def finished(self):
> >          """See progress.ProgressBar.finished()."""
> 
> I (still) dislike these docstrings; they use up memory and hide the real
> docstring without adding anything useful.  (I know we talked about it
> before, no action is required for this commit.)  I would prefer if they
> could just be comments.

Do we have a bug open on the solution we came up with? Or a spec? Either
of those would be good - as a QA aspect of the code base its something I
might get around to post dapper :)

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060421/18070183/attachment.pgp 


More information about the bazaar mailing list