Will the output of "bzr status" change?

[John A Meinel]

Matthieu Moy wrote:
> Hi,
> 
> There have been a lot of discussion on this list about the output
> format of "bzr status", whether it's good or not...

We are currently discussing having some sort of mode where you will run
a bzr process, such that you connect to it using stdin/stdout, and keep
issuing commands into it, and it keeps replying to you.
This would be designed as a machine parseable interface (possibly XML,
possible RFC822, possibly newline delimited whitespace, possibly etc)
Mostly likely it will be configurable how you will talk, with maybe 2
reasonable forms supported.

This would actually be a start on having a real smart server, where it
can be talked to over ssh, or possibly over cleverly formatted http POST
messages (to a cgi script/bzr webserver).

We are working on refining a spec for it right now. I'm not sure how
everything will work out, but the Wiki page for it is here:
http://bazaar.canonical.com/SmartServer

I don't believe the specific output "bzr status" will change soon, since
it is designed to be somewhat human friendly.
However, we might end up with a "bzr --xml status" which would use the
formatting code from the previous work, and still give you a simpler
method of calling it.

Right now we are doing some serious discussions about how things will
turn out, so I can only give vague hints as to what has been discussed,
and what seems like it sounds good.

> 
> I should be able to implement a bzr-status into DVC rather soon, and
> I'd like to know how much I can rely on the output format. (I gave up
> with pymacs, not being able to do asynchronous calls is a blocking
> problem, and up to now, I didn't have problem with the command-line
> interface).

I'm surprised they don't support async, but I guess that is life. You
still would likely get better efficiency by keeping bzrlib loaded in
memory and reusing it somehow.

I also don't have a specific timeframe for any changes, just that it is
likely to be a route that bzr goes (some of it possibly soon, probably
before 1.0).

John
=:->


> 
> Implementing a parser for this format in Emacs-lisp is not a problem.
> Internationalization can be a problem, but I can call bzr with 
> "LANG=C bzr ...".  The only problem is that I don't want to hardcode
> this format in my lisp code if it may change in the future, so if the
> probability of a change is high, I'll write a python wrapper that has
> a fixed output format.
> 
> [ People not interested in DVC can stop here ;-) ]
> 
> I think I'll implement bzr status in a way similar to what Xtla does
> for M-x baz-lint RET : display in a buffer something that looks like
> the output of "bzr status" (but after parsing it and rebuilding it so
> that further manipulation is easier). Operations on a file entry will
> apply to this file, and operations on a group name (modified:,
> unknown:, ...) will apply to all the files in this group.
> 
> The idea is to provide the user an interface similar to the command
> line, so using DVC-bzr should teach the user how to use bzr, but it
> also provides more features and an integration in Emacs.
> 
> Thanks for your comments,
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051105/e9cd846c/attachment.pgp