[MERGE] Output refactoring and XML integration into bzrlib

[Martin Albisetti]

On Nov 29, 2007 3:59 PM, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> Perhaps you could expand on what bzr-eclipse uses it *for*?

bzr-eclipse uses the XML output to be able to interact with bzr
without having any kind of binding or reading the FS. Just executes a
bzr command to get whatever information is needed, parses it, and then
does whatever magic it wants in eclipse itself.

On the other hand, as another example of usage, I have hacked my
companies workflow software to integrate bzr, and it's getting much
more tightly integrated (much more the Launchpad, for example).
As our software is in PHP, the quickest solution was to use
Guillermo's plugin to execute bzr commands and parse the XML output
into our DB.
PHP already has XML parsing functions natively, so if bzr provided XML
by default, I could release into the wild the php<>bzr bit and not
require users to install anything else.

I can imagine thousands of use cases where it would be useful to have
a machine-parseable output like XML to integrate it into other
applications.
And again, SVN has this natively.



> bzr has XML mostly in its storage formats.  For example, bzr revisions
> are already stored as XML.  So your XML log is essentially doing a lossy
> conversion from one XML format to another.  It seems redundant, and may
> be counterproductive, since the XML logger may discard information you
> later decide you want.

So you're saying we should be parsing the XML in the .bzr/ subdir?
I'm not sure we want to reimplement all the querying functions bzr has
and start hitting the filesystem directly.
Of course, I might be missing something, so if there is a better
approach at this, we'll be more then happy to scrap everything and
start again.

> I would really rather back up, and look at the design goals and use
> cases.  Because right now, we're not really communicating.  Until I have
> a better idea what you're trying to achieve, and why you're doing it the
> way you are, I can't really speak intelligently about what the right
> approach is.

This is what we've done. No more coding until we're all on the same page.

I also realize 1.0 being so close and the whole packs-format thing in
the air doesn't exactly put this very high up on the priority list.
Not really in a hurry to get this in, I just feel it's important it
does at some point.

Guillermo might also be able to give some more insight in this issue
as he's behind most of the bzr-xml and all the bzr-eclipse code.


Cheers!


Martin