bzr status: add non-recursive option

Bug #287880 reported by Todd
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Bazaar
Confirmed
Medium
Unassigned
Breezy
Triaged
Wishlist
Unassigned

Bug Description

I would like to request a "--non-recursive" option be added to "bzr status", similar to what is already done for the "bzr ls" command.

Tags: status ui
Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 287880] [NEW] bzr status: add non-recursive option

On Thu, 2008-10-23 at 01:14 +0000, Todd wrote:
> Public bug reported:
>
> I would like to request a "--non-recursive" option be added to "bzr
> status", similar to what is already done for the "bzr ls" command.

status really is quite a different command; from IRC I know this is for
a GUI - its really much better to just grab all the status data rather
than dir at a time - its much more efficient for something invoking bzr
repeatedly. (startup time can be 90% of the time to do a full tree
status, so doing 1000 dirs by calling bzr on each one will cripple your
performance).

--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

Revision history for this message
Todd (twhitema) wrote :

Use case: I make this request for Komodo IDE, a GUI editor, which has recently added support for bzr. Komodo will show status information (normal, edit, unknown, etc...) for file(s) and directories, but often this is only necessary on particular files/directories the user has opened/referenced.

Note: Komodo integrates with bzr using the command line (yes, I've seen the xmlrpc and python bzr libraries, and it's not an option at this time).

Revision history for this message
Aigenta Dev (dev-aigenta) wrote :

>doing 1000 dirs by calling bzr on each one will cripple your performance

Correctly. However, checking status for all thousands files in the subtree will impact performance very badly, when status of _only one_ directory is needed actually.
So, add this option. Please.

Revision history for this message
Robert Collins (lifeless) wrote : Re: [Bug 287880] Re: bzr status: add non-recursive option

On Thu, 2009-08-06 at 11:23 +0000, Aigenta Dev wrote:
> >doing 1000 dirs by calling bzr on each one will cripple your
> performance
>
> Correctly. However, checking status for all thousands files in the subtree will impact performance very badly, when status of _only one_ directory is needed actually.
> So, add this option. Please.

Actually, doing status on all of openoffice is about 1.8 seconds. We've
made status very efficient. Its not to say we won't eventually add a
non-recursive option, but there are many other areas where we are overly
slow, and status isn't currently one of them (to the best of my
knowledge).

-Rob

Revision history for this message
Martin Pool (mbp) wrote :

2009/8/7 Robert Collins <email address hidden>:
> On Thu, 2009-08-06 at 11:23 +0000, Aigenta Dev wrote:
>> >doing 1000 dirs by calling bzr on each one will cripple your
>> performance
>>
>> Correctly. However, checking status for all thousands files in the subtree will impact performance very badly, when status of _only one_ directory is needed actually.
>> So, add this option. Please.
>
> Actually, doing status on all of openoffice is about 1.8 seconds. We've
> made status very efficient. Its not to say we won't eventually add a
> non-recursive option, but there are many other areas where we are overly
> slow, and status isn't currently one of them (to the best of my
> knowledge).

Even if it's the same time as doing the whole tree, it might be easier
for them to deal with the output restricted to one directory...

--
Martin <http://launchpad.net/~mbp/>

Changed in bzr:
status: New → Confirmed
importance: Undecided → Medium
Jelmer Vernooij (jelmer)
tags: added: status ui
Revision history for this message
Kevin Bulgrien (kbulgrien) wrote :

I would like to see this bumped in priority. The request was posted in '08 and it is now '12. There are use-cases where non-recursive status is important. This is also perhaps more important to people coming to bzr from other VCS where it is available. Bzr seems to place a higher priority on supporting a variety of use cases and work flows. In my case, I use the limit recursion option a lot in the VCS I am trying to move away from. This is one of those things that is reasonable, even from the point that other commands have a --no-recurse option. It seems silly to have to get status on much more than what one is working on at the moment, even if it is "efficient" from a software point of view. It is inefficient for a user to have to sort through more information coming out of status than what is wanted.

Part of the reason I think it is important is that I have a use case where there are unreadable files in the lower trees. bzr status aborts when it sees those unreadable files. Unless I can limit recursion, it is going to be hard to use bzr the way I use my other VCS in this use case. While it is acknowledged that there are alternative ways to approach this problem - and that my particular use case may not be particularly common, it seems reasonable to have bzr to act like other VCS by offering no recurse when getting status.

Jelmer Vernooij (jelmer)
tags: added: check-for-breezy
Jelmer Vernooij (jelmer)
tags: removed: check-for-breezy
Changed in brz:
status: New → Triaged
importance: Undecided → Wishlist
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.